Connecting a component library to Claude

There is the directory listing, the server by hand, and the plugin. All three lead to the same MCP server; they differ in where the connection is stored and how much comes along besides the tools.

The first route is the shortest. Anthropic runs a connector directory, and the documentation describes it as one catalog serving claude.ai, Desktop, mobile, Cowork and Claude Code at once. A provider submits a server once, and anyone who wants to use it opens the listing and clicks Connect. There is no address to type out and no key to copy.

The second route is the server by hand, in Claude Code through a command in the terminal. The third is the plugin, and it is the only one of the three that delivers more than a line: alongside the server it holds skills, subagents, hooks and commands of its own. Which route is right depends less on skill than on where you work with Claude.

Through the directory, in one click. You open the provider's listing, click Connect and sign in with your account at the provider. For Systra Tools that listing sits at claude.ai/directory/systra-tools, and after the sign-in the server brings the scope belonging to that account, with no key stored anywhere.

Where there is no listing, you create the connector yourself: under Customize, Connectors, Add custom connector, and enter the server's address there, for Systra Tools systra.tools/api/mcp. In the dialog you choose how signing in works. Sign in now runs the provider's login right away, sign in when needed waits until the server asks, and no sign-in is meant for servers that know no users. A fixed key can only be stored in that last case, as a request header, and that option is a beta according to the documentation, one not every organization sees.

Two things are easy to miss here. On a Team or Enterprise plan an Owner adds the connector for the organization and members then connect with their own account: the listing is shared, the sign-in is not. And in an individual conversation every connector can be switched off through the plus button, which is the most common explanation for a connected server suddenly not answering.

It brings the instructions along. An MCP server delivers tools, a search and the delivery of source code, say. A plugin in Claude Code bundles skills, subagents, hooks and commands of its own beside them and installs all of it in one step. For a component library that is exactly the difference that counts day to day: the tools alone do not change the fact that a model would rather write a section itself than search for one.

Installing takes two lines, and between them sits a step worth knowing. The first line registers the marketplace, meaning the place the plugin lives, the second installs the plugin from it. Since Claude Code 2.1.275 both also fit in one line, by hanging the source onto the install command with --marketplace. Inside a session the install command first opens the details, and those say what the plugin brings before you agree.

Before agreeing you choose the scope, and that is the real decision. For you on this machine lands in your own settings. For everyone in the repository lands in a file you commit, which switches the plugin on for your colleagues but does not download it: each of them runs the install once themselves. For you in this repository only stays in the local settings and is nobody else's business.

They hang the connection on a file instead of on an account. That is the one difference all the others follow from. In Claude you connect, and the connection is yours: it is there in every conversation, on every device, and nobody else gets anything from it. In Cursor and VS Code you enter the server into a file, and that file sits either in your home directory, where it applies to all your projects, or in the project, where it applies to everyone who opens it.

The formats differ in details you notice while typing. Cursor expects a block called mcpServers holding an address and optional headers per server, in ~/.cursor/mcp.json globally or in .cursor/mcp.json per project. VS Code expects a block called servers in .vscode/mcp.json, with an additional type set to http, and knows a second block beside it called inputs.

That second block is the genuinely interesting part, because it solves a problem Claude never has in the first place. A project file gets committed, so a key inside it lands in the repository. With an entry of type promptString, VS Code asks for the key once on first start, remembers it locally and inserts it at runtime. All that remains in the file is a placeholder. If you want the same effect in Cursor, put the configuration in your home directory rather than in the project.

Because nobody told it when to. This point is left out of almost every tutorial, and it is the reason a correctly configured connection can feel as though it does nothing. A connected server shows up as a list of tools. The model sees that list, but it has no reason to use it as long as the obvious move is to write the section itself. So it does what it is good at anyway.

The counter-measure is a file in the project, usually AGENTS.md, saying when the library comes into play. It does not have to be long. Three instructions carry a long way: before a new section, search first; take the delivered source rather than rewriting it; fetch images through the tool meant for it. What matters is the order inside the sentence, search first and build second, because that order is precisely the one the model does not pick on its own.

On the other end of the same line sits the question of whether the library itself is readable for models. A file called llms.txt on the website answers the questions a model asks, in the form it asks them: what is this, how many building blocks, which technology, what does it cost, how do I connect it. That is not an SEO trick, it is the same work as good documentation, only for a reader who uses no navigation and opens no second page.

Five things, and none of them announces itself with an error message. Together they explain most cases where the setup is right and still nothing happens.

That leaves the question of when the whole effort is not worth it. For a single project needing three components, copying from the browser is faster than any setup. The benefit comes from repetition, meaning where searching, comparing and placing happens again and again over weeks, and where several people should draw on the same source.

And a connection replaces no decision. An agent that can reach a library does not therefore build a good page: it finds what exists faster and places it more cleanly. Which of it belongs where remains a question that sits upstream of the tool.