MCP server: which one to wire, and on what terms

An MCP server, and the two ways to run one

An MCP server is a program that exposes capabilities to an AI application. The official documentation puts it plainly: the word server refers to the program serving context, regardless of where it runs. So it is not necessarily a remote machine, and that is the first source of confusion.

It exposes three things. Tools, functions the model can call. Resources, data to read. Prompts, conversation templates. On the client side one capability remains in the current version: elicitation, which lets the server ask the user for information or a confirmation.

The choice that shapes everything else is the transport, and there are only two.

A filesystem server launched by your desktop client runs over stdio on your machine. An observability server operated by the product vendor runs over HTTP on theirs. Both are called MCP servers, they do not share a threat model, and conflating them is the first scoping mistake.

Where to find the ones that exist, and what that guarantees

An official registry exists, with a moderation policy and third-party aggregators relaying it. Alongside it, the modelcontextprotocol/servers repository hosts reference implementations, including the filesystem server the documentation uses as its example. And most serious vendors now publish their own.

That covers availability. On trust, let us be clear: being listed in a registry is not a security audit. A moderated registry filters out the crude cases, it does not verify what the code does with your data once running.

The official documentation goes further, and this is the sentence to keep from this whole article: descriptions of tool behaviour, annotations included, should be considered untrusted unless they come from a trusted server. In other words, what a server says about itself proves nothing. The only model that holds is the software dependency model: you install it because you trust who publishes it, not because its description reads well.

The five questions to ask before wiring one

These five points come from the risks the official security documentation describes itself. They are not precautionary principles, they are documented attacks with their countermeasures.

1. Does the server run locally? A local server is a binary downloaded and executed on your machine, with your client's privileges. The documentation explicitly lists data exfiltration and privilege escalation through a malicious startup command. A correct client must show you the exact command, untruncated, before running it.
2. What is the real scope of the exposed tools? A tool is arbitrary code execution. The list is discovered through tools/list, and it can change mid-flight, since the server may notify a change. What was safe yesterday is not guaranteed safe tomorrow.
3. Who issued the token? The specification is categorical: an MCP server must not accept any token that was not explicitly issued to it. A server that forwards your token to a downstream API without validating its audience is a problem, not an integration.
4. How is state bound to the user? The protocol is stateless, so a server that must remember something mints a handle the client sends back. The rule: possession of a handle is not authentication. Without server-side binding to the account, anyone guessing a handle acts as you.
5. Does the server act as a proxy to a third party? This is the trickiest case, the confused deputy: a badly built proxy lets an attacker collect an authorization code with no consent, by exploiting a cookie set during a legitimate session.

These five questions take ten minutes and rule out most bad surprises. What they do not rule out is the need for a written action policy: what goes out automatically, what needs human confirmation, what stays forbidden. A well-chosen server wired without that policy is still a system that can act alone on real data.

Which servers are worth wiring

Rather than a ranking that will be stale in three months, here are the families that earn their place and the risk specific to each.

So the best MCP server is the one whose publisher you know, whose code you can read, or whose product you already pay for. Those three criteria eliminate most of the catalogue, and that is fine: value does not come from the number of servers wired. Every extra tool takes up context window, widens the attack surface and adds one more path for an answer to go wrong.

In practice, on the projects we ship, three to five well-chosen servers cover everything that matters. Beyond that we mostly see agents hesitating between redundant tools.

What changed on 28 July 2026

The current specification version is dated 28 July 2026, and it moves enough for earlier tutorials to mislead.

The protocol is now stateless. Every request carries its version and the capabilities relevant to it, so the server infers nothing from earlier exchanges. A mandatory server/discover request lets the client learn the accepted versions and capabilities before anything else, with responses that can be cached.

Two client-side capabilities are deprecated: sampling, which let a server request a completion from the client, and logging. The documentation points to direct integration with provider APIs for the first, and to stderr or OpenTelemetry for the second. A server still relying on them is a server that has not kept up.

Change notifications are now explicitly requested: the client opens a stream and names the event types it wants. Nothing arrives by default any more.

So if you are evaluating a server today, the first technical question is simply which version it advertises. It shows from the discovery step, and it says a lot about how well the project is maintained.