Learn about MCP

What the protocol is, what a server and a client actually do, how it differs from a CLI or an API, and where to ask when something does not work.

What is new in the catalogue

Each time a batch of servers arrives we write up what came in: what the notable ones do, who publishes them, what it takes to run them, and what changed about the shape of the batch. Windows tile with no gaps, so nothing is skipped between posts. Read them at /blog/.

Read the roundups

What is the Model Context Protocol?

MCP is an open protocol for connecting an AI assistant to the systems it needs to do real work. Before it existed, every assistant and every tool needed a bespoke integration, which is why so few of them could touch anything outside their own chat window.

The protocol defines three things a server can offer. Tools are actions the model can call, such as searching a database or filing a ticket. Resources are pieces of content the model can read, such as a file or a record. Prompts are reusable templates a server suggests to the client. A client discovers what a server offers by asking, so neither side needs to be updated when the other changes.

It was created by Anthropic, released in November 2024, and has since moved to open governance. The specification and the SDKs are permissively licensed, which is why the ecosystem grew to tens of thousands of servers in under two years.

What is an MCP server?

An MCP server is a small program that sits between an AI client and one specific system. A Postgres server exposes queries. A GitHub server exposes repositories and issues. A Stripe server exposes payments. Each one translates between the protocol and whatever API or file system it wraps.

Servers come in two shapes, and the difference decides what you can use. A local server runs as a process on your own machine and talks to the client over stdio. You install a package first, and your data never leaves your machine. A hosted server runs on the publisher's infrastructure and the client connects over HTTP. There is nothing to install, but your requests go to a third party.

That distinction is why a client matters as much as a server. An assistant that runs in the cloud, such as ChatGPT or an automation platform, cannot start a process on your laptop, so it only works with hosted servers. A desktop client can do both.

What is an MCP client?

The client is the application you actually type into: a code editor, a desktop assistant, a terminal agent, or a workflow platform. It holds the model, discovers what each connected server offers, and decides when to call a tool.

Support is uneven, and that is the single most common source of confusion. Plenty of clients implement tools but not resources, prompts or sampling, so a server whose value lies in those features will feel broken even though nothing is wrong with it. Transport support matters just as much: a client that cannot spawn a local process is limited to servers with a hosted endpoint.

Configuration also varies more than it should. Some clients read a JSON file, some a YAML file, some take a command, and the automation platforms configure everything through their own interface with no file at all.

How is this different from a CLI or an API?

An API is for a programmer who knows in advance which call to make. A CLI is for a human at a terminal. MCP is for a model that has to decide, at run time, which of several hundred available actions is the right one, using only the descriptions it was given.

That is why tool descriptions matter so much in practice. The model has nothing else to go on. A well described tool gets chosen correctly; a vaguely described one gets skipped or misused, no matter how good the underlying code is.

Several vendors now ship both, and the two are not really alternatives. The CLI is for you, the MCP server is for your agent, and they often wrap the same API. A growing number of tools fold the server into the CLI as a subcommand, so one install gives you both.

How do I choose between servers that do the same thing?

There are usually several servers for any popular system: one from the vendor and a handful from the community. Four questions separate them quickly.

Who published it? A namespace tied to a company domain means the publisher proved they control that domain. A namespace beginning io.github means anyone with a GitHub account. Neither is a quality judgement, but the first tells you who to hold responsible.

Is there a source repository, and has it been touched recently? An archived repository or one with no commits in a year is a maintenance risk regardless of how good the code is.

What credentials does it want, and does that match the job? A server that asks for full account access to read one report is asking for too much. Prefer read only scopes, and prefer servers that document each variable.

Can your client actually use it? Check the transport before anything else. It is the most common reason a correctly installed server does nothing.

What should I be careful about?

The MCP Registry applies minimal moderation by design. Its own documentation says consumers should assume close to none, and that low quality, buggy, vulnerable and duplicate servers are not removed. A listing anywhere, including here, is not a security review.

Treat an MCP server as you would any dependency that gets your credentials. Read the source if it is published. Give it the narrowest scope that works. Prefer read only until you have watched what it does. Be especially careful with servers that can spend money, post publicly, or delete things: ad accounts, payment processors, social platforms and databases with write access.

Tool annotations help. A server can mark a tool as read only, destructive, idempotent or open world, and a good client surfaces those hints. Where a server declares them, this catalogue shows them on the tool list.

How this catalogue works

The score is out of 100 and measures how well documented and verifiable a server is, not how good it is. The methodology page states every weight, names every source, explains how tool intent is labelled and how much of it is our inference rather than the publisher's own declaration, and says plainly what the score cannot tell you. Read it at /methodology/ before treating any number here as a verdict.

How this catalogue works

Guides written here

Written from measured data rather than opinion. Each says how it was measured so you can judge it.

Documentation and tools

Primary sources. Prefer these to any tutorial, including this page, when the two disagree.

Communities on Reddit

Where problems get posted before they reach any documentation.

Chat communities

Only real Discord invites are listed. Where a project publishes chat only behind a sign in, or where the invite could not be confirmed, nothing is listed rather than a link to a homepage that may or may not lead anywhere. Invites are collected automatically from publisher websites, including their footers, so a dead one will drop off a later build rather than linger.

Publisher run servers found in the catalogue

Collected automatically from publisher websites and their footers while building the catalogue. 385 invites from 385 publishers. These belong to individual vendors rather than the protocol community, so they are the place to ask about one specific server.