Best MCP servers: how to actually pick one

The best MCP server for a given job is the one that does what you need and passes the checks that apply to how it is shipped. For a packaged server you download and execute, those are supply-chain checks: provenance, install scripts, known vulnerabilities in the dependency tree. For a remote HTTPS endpoint you never run, they are connection and operator checks: authentication, transport, TLS, domain control. The two sets barely overlap, so “best” means something different depending on which one you are installing.

That matters because most published servers fail a good number of those checks. On 18 August 2026 we scored 22,667 servers from the official MCP registry, and the median server’s best-scoring component came in at 51 out of 100. Just 2,524 of them, 11.1% of everything scored, reached the 80-plus band we label high trust. The live version of that distribution is on our stats page.

Individual scores also move: a dependency picks up a CVE, a maintainer stops answering, an endpoint changes its transport. So this page sets out the criteria and shows where to look up the current answer for a specific server, rather than fixing a ranking in place.

What does “best” mean for an MCP server?

It depends on which of two things you are installing, because they fail in completely different ways.

A packaged server from npm, PyPI, NuGet, a container registry or an MCP bundle is code you download and execute on your own machine. It is a dependency with execution rights, and the questions that matter are supply-chain questions: who published it, was the artefact built from the source you can read, does it run a script at install time, does its dependency tree carry known vulnerabilities. 12,442 of the registry’s 25,124 components are these.

A remote server is an HTTPS endpoint you hand context and tool calls to. You never run its code, so the risk sits in the connection and the operator: is the transport current, is TLS configured properly, does it authenticate you, is the domain protected against hijack. 12,682 components are these, and 1,487 of them declare a required secret header in their registry entry, which is a floor on how many actually gate access rather than a measurement of it.

“Best” for a packaged server and “best” for a remote endpoint are close to unrelated judgements, so the two are worth assessing separately.

Why is popularity a poor proxy for quality?

Because the things that make a server popular are visible from the outside and the things that make it safe are not.

Stars measure how many people liked the idea. Downloads measure how many people tried it, often once. Neither is affected by whether the published artefact matches the repository, whether the lockfile is committed, or whether the maintainer has been absent for eighteen months. A widely recommended server can still fail most of the checks below, and only 2,524 servers sit in the high-trust band.

We cannot put a number on the relationship between the two, because popularity is not one of the things we measure. The scored population sits at a median of 51, which is the population popular servers are drawn from as well.

Which checks actually matter?

These are the questions worth answering before you install anything, in roughly the order they change your decision.

For a packaged server:

• Is the artefact traceable to its source? Build provenance ties the published package to the commit and the workflow that produced it, following the SLSA framework. Without it you are trusting that the tarball matches the repository you read. See build provenance.
• Does anything run at install time? An install script executes before you have decided to trust the package. See install scripts.
• Are there known vulnerabilities in the tree? Not just the top-level package. We resolve against OSV, the open vulnerability database. See vulnerabilities.
• Is there a lockfile? It is the difference between shipping what was tested and shipping whatever resolved today. See lockfiles.
• Is it maintained, and does the repository link actually resolve? See maintenance and repository.
• Is there a security policy? It decides whether a reported issue reaches anyone. See security policy.

For a remote server:

• Does it authenticate, and correctly? A bare 401 is not enough; a client needs to be told where to get a token, which is what RFC 9728 protected-resource metadata is for. See authentication.
• Is the transport current? See transport.
• Is TLS configured properly, with HSTS? See TLS and HSTS.
• Is the domain protected against hijack with DNSSEC? See DNSSEC.
• Is it stable, and does it declare a current protocol revision? See stability and protocol version.

Each list applies to its own kind of component, so a packaged server is never marked down for lacking DNSSEC. Every check above is a signal we compute on every component we can reach, and each one links to a guide for fixing it if the server is yours.

Which MCP servers work with Claude, Codex and other clients?

Most of them, and that is the point of the protocol. MCP is a standard, so servers are not written for one client: a client can connect to any server whose transport and protocol revision it supports. Claude Code, Claude Desktop, OpenAI Codex, Cursor, VS Code, Gemini CLI, Windsurf, Cline, opencode and ChatGPT all speak MCP, so searching for servers scoped to one of them narrows the field more than the compatibility question warrants.

Three things do vary by client, and none of them is about the server:

• Transport support. A client that runs on your machine (Claude Code, Codex, Cursor, VS Code, opencode) can launch a packaged stdio server as a child process. ChatGPT on the web cannot: it connects to remote endpoints over Streamable HTTP or SSE, so a packaged server has to be hosted somewhere first. Check which kind you are installing, not which client it was written for.
• Which tools the client will call. A client can support MCP and still ignore most of a server’s tools. ChatGPT’s standard custom connectors surface only search and fetch; its developer mode, available to Pro, Plus, Business, Enterprise and Education accounts on the web, exposes every tool a server declares, write actions included. Those require confirmation by default, but a user can choose to remember that approval for the rest of a conversation, so do not treat the prompt as a guarantee that a human sees every write.
• Configuration format. Each client stores its server list differently, so the same server needs a different config entry per client. That is a client question, answered in each client’s own documentation.

Settle the transport question before the client question. A stdio-only server is unavailable to anything running in a browser, and a remote endpoint reaches every client at the cost of trusting an operator whose code you cannot read.

How do you find the current best servers?

Scores change, so use a live view rather than a fixed list:

• The directory is the searchable, filterable, rankable surface. Sort by score, filter to what you need.
• Browse groups every catalogued server by how it is distributed, or lists them alphabetically.
• Browse by product is the right entry point when you already know the system you want to connect to, which is how most people arrive.
• Compare puts servers side by side when you have narrowed it to a shortlist.

In practice the question is usually narrower than “what are the best MCP servers”: it is “what is the best server for the system I need to connect to, and is it good enough to run”. Those are two separate answers, and only the second one is about trust.

What if the server you need scores badly?

Frequently it will, given the distribution. That is a decision, not a blocker.

A low score tells you which specific signals failed, so you can decide whether they matter for your use. A server with no build provenance that you run locally against test data is a different risk from the same server holding production credentials. Read the breakdown on the server’s page, look at what actually failed, and weigh it against what you are about to give it access to.

If it is your own server that scores badly, every failed signal deep-links to the guide that fixes it, and the MCP security checklist collects the checks into two lists you can run yourself. Start with claiming the server so the registry entry points at you.

Where to go next

• Choosing: the directory for the live ranking, and the security checklist for the checks behind it.
• Understanding the score: how we score MCP servers sets out the rubric, the weights and the critical caps.
• Testing a candidate yourself: the MCP Inspector shows you what a server actually exposes before you wire it into anything.

The registry is large and its scores move week to week, so the durable part is the method: know which questions apply to the kind of server you are installing, and where to look up the answers for the specific one in front of you.