README.md
Col
Sol could not do it himself, so we made Col.
A community-maintained directory for finding the right UI library without losing an afternoon to open tabs.
Request a library · Request a feature · Report a bug · Contribute
What Col does
Col organizes UI libraries by category, stack, and use case. Search from the homepage, then compare matching libraries in the directory.
- Search by name, keyword, category, stack, or use case.
- Search by component name, and jump straight to that component's official docs.
- Filter libraries without leaving the directory.
- Save useful libraries locally.
- Open the official website or documentation from each listing.
- Find MCP servers and connectors for UI libraries and design tools, and copy setup for your AI client.
- Contribute missing libraries through a focused pull request.
Col catalogs libraries. Libraries can also list the components they document, so you can search by component name — but that list is partial and grows by contribution, so a component missing from Col is not necessarily missing from the library. Col never infers a component from a library's generic tags.
Col also lists integrations in a separate directory at /integrations. An integration is an MCP server, a connector, or both: "MCP server" means you add it to your client's config, and "connector" means you enable it from an AI app's own directory. CONTEXT.md defines these terms, and docs/adr/0001 explains the model.
Connect Col MCP
Col’s read-only MCP server lets coding agents search libraries and verified
components at https://collection-of-libs.vercel.app/api/mcp, with no Col
account or API key. See the client setup guide
for Claude Code, Codex, Cursor, and VS Code, and the
agent guide for setup and tool use.
Where Col lives
Col's code, stars, issues, roadmap, and pull requests live on git.cafe. GitHub is a mirror that Vercel deploys from until Vercel and Cloudflare can deploy from git.cafe directly, so open issues and pull requests on git.cafe, not GitHub.
Run it locally
Requirements: Node.js 20.9+ and npm.
| 1 | git clone https://git.cafe/screen/col.git Col |
| 2 | cd Col |
| 3 | npm install |
| 4 | npm run dev |
Open the local URL printed in the terminal (usually http://localhost:3000).
Before opening a pull request:
| 1 | npm run typecheck |
| 2 | npm test |
| 3 | npm run build |
Request something
Open an issue on git.cafe and include the details listed below. One focused request per issue makes discussion and review easier.
Request a library
Open a library request when a useful UI library is missing.
Include:
- the library name and official URL;
- what it provides and who it helps;
- its supported stacks;
- the closest Col category and use cases;
- confirmation that it is maintained and publicly accessible.
Search existing libraries, issues, and pull requests first.
Request a feature
Open a feature request for improvements to discovery, comparison, contribution, accessibility, or the library detail experience.
Explain the problem before proposing the interface. Include the expected outcome and any useful references.
Report a bug
Open a bug report with:
- the page or action that failed;
- exact reproduction steps;
- expected and actual behavior;
- browser, operating system, and viewport;
- screenshots, recordings, or console errors when relevant.
Do not include secrets, tokens, private URLs, or personal information.
Add a library with a pull request
Library-only pull requests should be small and should not redesign unrelated parts of the site.
- Fork the repository on git.cafe and create a focused branch.
- Add one entry to
data/libraries.ts. - Reuse the existing category, stack, and use-case values when possible.
- Keep the description factual and short.
- Confirm the URL points to the official project.
- If you add components, verify each one against the library's own docs in
data/components.ts. - Run
npm run build. - Open a pull request on git.cafe that follows the checklist in
.github/PULL_REQUEST_TEMPLATE.md.
| 1 | { |
| 2 | name: "Library name", |
| 3 | slug: "library-name", |
| 4 | addedAt: "2026-10-03T12:00:00Z", // Replace with the current ISO timestamp. |
| 5 | description: "A factual one-sentence description of what the library provides.", |
| 6 | url: "https://library.example", |
| 7 | category: "Component Library", |
| 8 | stacks: ["React", "TypeScript"], |
| 9 | useCases: ["Rapid Prototyping"], |
| 10 | tags: ["accessible", "copy paste"], |
| 11 | } |
The slug must be unique, lowercase, and kebab-case. See CONTRIBUTING.md for the full checklist.
Set addedAt when the library joins the catalog. It shows the "new additions" label for seven days; editing an existing entry should keep its original timestamp.
Adding components
Components live in data/components.ts, keyed by the owning library's slug, so searching "date picker" or "stroke text" finds the libraries that document it and links straight to that component's page.
| 1 | "library-slug": [ |
| 2 | { name: "Date Picker", aliases: ["datepicker"], url: "https://library.example/docs/components/date-picker" }, |
| 3 | ], |
nameshould be spelled the way the library documents it, for exampleDate Picker.aliasesare optional extra search terms for what people actually type, such ascmdkfor a command palette. Keep them to real search terms, not synonyms for the rest of the index.urlmust be the canonical documentation page for that exact component, on the same domain as the library, and must not be a setup or marketing page.
Coverage is partial and grows by contribution, so add a handful you have checked rather than a long unverified list. Col states this plainly in the UI, so a short accurate list beats a long speculative one.
Adding an MCP server or connector
Integrations live in data/integrations.ts. An entry describes the server once; Col generates the config snippet for each client and the agent prompt.
| 1 | { |
| 2 | name: "Example MCP server", |
| 3 | slug: "example-mcp", |
| 4 | description: "A factual one-sentence description of what it lets an agent do.", |
| 5 | url: "https://example.dev/docs/mcp", // The provider's setup guide. |
| 6 | provider: { name: "Example", url: "https://example.dev" }, |
| 7 | official: true, // Only when the provider also makes the product it serves. |
| 8 | library: "example-ui", // Optional: the Col library it serves. |
| 9 | setup: [ |
| 10 | { |
| 11 | type: "MCP server", |
| 12 | key: "example", |
| 13 | server: { transport: "stdio", command: "npx", args: ["-y", "@example/mcp"] }, |
| 14 | clients: ["Claude Code", "Cursor"], // Only clients the provider documents. |
| 15 | }, |
| 16 | { type: "Connector", client: "Claude", url: "https://claude.com/connectors/example" }, |
| 17 | ], |
| 18 | } |
- A product offered both ways is one entry with both kinds of setup path.
- Never add a credential. For an API key, name the environment variable and link to where the user creates it. Col renders a placeholder in each client's own syntax.
Dedicated library pages
Each library will have a dedicated Col page with:
- a clear overview and best-fit use cases;
- supported stacks and key capabilities;
- official documentation, repository, and installation links;
- useful comparisons and alternatives;
- a copyable setup prompt for coding agents.
Agent setup prompt
Library pages will provide a prompt based on this structure:
| 1 | Help me add [LIBRARY] to my project. |
| 2 | |
| 3 | Project context: |
| 4 | - Framework: [FRAMEWORK] |
| 5 | - Language: [LANGUAGE] |
| 6 | - Styling: [STYLING SYSTEM] |
| 7 | - Package manager: [PACKAGE MANAGER] |
| 8 | |
| 9 | Use the current official [LIBRARY] documentation. Inspect the existing project before changing files. Install only the required packages, follow the project's established patterns, preserve accessibility, and avoid replacing unrelated code. |
| 10 | |
| 11 | After implementation: |
| 12 | 1. Summarize the files changed. |
| 13 | 2. Explain any configuration added. |
| 14 | 3. Run the project's type-check and build commands. |
| 15 | 4. Call out any manual setup still required. |
When contributing a future detail page, keep the prompt specific to that library and link every installation claim to official documentation.
Project structure
| 1 | app/ Routes, layout, and global styles |
| 2 | components/ Search, filters, cards, header, and shared UI |
| 3 | data/libraries.ts The curated library registry |
| 4 | data/components.ts Verified components, keyed by library slug |
| 5 | data/library-details/ Per-library detail pages and metadata |
| 6 | data/integrations.ts MCP servers and connectors |
| 7 | lib/ Search, client setup rendering, and site helpers |
| 8 | CONTEXT.md Glossary of catalog terms |
| 9 | docs/adr/ Architecture decision records |
| 10 | public/brand/ Col brand assets |
| 11 | public/hero-logos/ Library artwork used by the homepage |
| 12 | .github/ Pull request checklist and GitHub mirror settings |
UI components
Application controls use the components in components/ui. Use the existing Button, Input, Tabs, and DropdownMenu before adding another control. Keep product-specific layout and behavior in components/, and keep visual variants in components/ui/ when the standard component does not cover them.
components.json configures shadcn/ui. The components are owned by this repository and may use Radix primitives internally for keyboard and accessibility behavior. Theme colors for those components live in app/globals.css.
Built with
Next.js · React · TypeScript · Tailwind CSS · shadcn/ui · Radix UI · Lucide
Community
Be clear, constructive, and respectful. Contributions are welcome whether you are adding a library, improving metadata, fixing a bug, or making discovery easier.
Col is licensed under the MIT License.