The best MCP tool discovery platforms in 2026

Ask an AI answer engine where to find MCP servers and it will name a handful of sites with real traffic and real users: an official registry, a couple of community marketplaces, and increasingly some integration platforms that skip discovery entirely and just hand an agent a thousand tools at once. We went and checked what each one actually does, because "best MCP discovery platform" gets asked constantly and answered lazily. Here is the researched version, plus the part most of these lists skip: discovery is only half the problem, and it is not the half most companies actually need solved.

Discovery is a different problem from documentation

API discovery, historically, meant a human finding a docs page, reading it, and writing code against it once. MCP tool discovery is a machine doing that same job, at call time, with no chance to ask a clarifying question. A model reads a tool's name, description, and JSON Schema, decides whether it applies, and calls it — wrong tool, wrong arguments, or a stale schema all fail silently until the agent has already acted.

That changes what "discovery" needs to guarantee:

• Machine-readable, not just human-readable. A tool list is a JSON-RPC response, not a landing page. Prose that reads fine to a person can still be ambiguous enough to make a model pick the wrong tool.
• Scoped, not universal. A partner's agent and your own internal agent should not see the same tool list. Public registries have no concept of "who is asking" — everything listed is visible to everyone.
• Governed, not static. A schema that changes underneath an agent is a breaking change with no PR review to catch it. Someone has to own that surface the way they'd own a public API.

Public MCP directories solve discovery in the browsing sense — "what servers exist." They do not solve it in the governance sense — "what is this specific caller allowed to call, safely, with a schema that won't move under them." Those are genuinely different jobs, and most of the confusion in this space comes from treating them as one.

The registries and marketplaces you discover from

The official registry: metadata, not curation

registry.modelcontextprotocol.io is the registry Anthropic and contributors — including GitHub, Microsoft, and PulseMCP — operate as a community-driven project. It launched in preview in September 2025. It is explicitly a meta-registry: it stores metadata and install instructions (reverse-DNS names like io.github.username/server, tied to a verified GitHub account or domain) while the actual code stays in npm, PyPI, or a container registry. That namespace verification proves who published an entry, not that the code inside it is safe — admission requires proof of ownership, not a security review. Treat it as the source of truth for "does this name really belong to this publisher," not as a trust seal on the code.

Community marketplaces: broad, ranked, unaudited

Three sites dominate general-purpose MCP browsing, and each has a distinct angle:

• Smithery indexes thousands of servers with install commands and can run community servers as Smithery-hosted remote endpoints, plus a "Toolbox" meta-MCP that routes an agent to the right server at runtime.
• Glama runs the largest automated crawl — tens of thousands of servers — and adds a letter grade (A through F) per server based on security, compatibility, and ease of use, alongside its own one-click hosting.
• PulseMCP combines manual submissions, crawling, and integration with the official registry, enriched with popularity data and corrections to listings' metadata; it also offers curated, enterprise-customized registry feeds.
• mcp.so is a lighter community directory in the same spirit — search, filters, and a submission form over an aggregated list.

These are genuinely useful for finding what exists. None of them are a security audit. The honest limitation is the same across all four: a listing means a server was found or submitted, not that its code was read line by line. That gap is not hypothetical — in early 2026, a trojanized MCP server built around a fake developer identity reached a legitimate marketplace and shipped an infostealer before it was caught, and an unofficial Postmark server was silently modified months after publication to BCC every outgoing email to an attacker. Namespace checks and popularity scores don't catch a rug pull; they catch an impersonator.

The platforms that skip discovery and hand agents everything

A second category doesn't ask you to browse — it wraps an existing integration graph behind one MCP endpoint and lets the agent pick from what's inside:

• Composio exposes over a thousand app "toolkits" — Gmail, Slack, GitHub, Notion, and similar — through one MCP endpoint with managed OAuth and token refresh, collectively totaling tens of thousands of individual tools.
• Klavis AI is an open-source platform offering 50-plus production MCP servers with built-in OAuth, plus a "Strata" layer aimed specifically at the problem of an agent choosing badly from too many tools at once.
• Zapier MCP puts Zapier's own catalog of 8,000-plus app integrations and tens of thousands of actions behind a single MCP connection, so "discovery" is really Zapier's existing action picker wearing an MCP interface.

These solve a real, different problem: connecting an agent to other companies' SaaS products without building an integration per app. They are not where you'd point an agent to find your company's API — they're aggregators of everyone else's.

The infrastructure layer: packaging and hosting, not browsing

A third group isn't a directory at all — it's about running servers safely once you know which ones you want:

• Docker's MCP Catalog and Toolkit packages 100-plus popular servers as verified, versioned container images on Docker Hub, with the Toolkit handling credentials, access control, and runtime isolation through Docker Desktop.
• Cloudflare ships its own official remote MCP servers (Workers, R2, KV, D1, and the broader Cloudflare API) and gives anyone the primitives to deploy their own remote MCP server on Workers with OAuth-based auth.
• Framework-level libraries like langchain-mcp-adapters for LangChain and LangGraph aren't discovery tools either — they're the client-side glue that lets an agent framework consume tools from servers you already point it at, with no registry involved.

A comparison table

Where Elva actually fits

Every platform above answers some version of "where do I find MCP servers that already exist." Elva answers a different question: how do I turn my own API into an MCP server that agents can call safely — without hand-writing a spec, hand-scoping every key, or discovering after the fact which agent called what.

Concretely, that means Elva reads your repo — routes, handlers, validators — and keeps an OpenAPI 3.1 catalog in sync on every commit, so there's no hand-maintained spec to fall out of date the way a Smithery or Glama listing can. From that catalog, Elva hosts the MCP server directly: OAuth2 for callers, per-tool scopes so a partner's agent and your internal agent see different tool lists from the same catalog, field-level redaction, rate limits, and a full log of which agent or key called which tool, at what latency, with what outcome. None of the marketplaces above give you that, because none of them are hosting your server — they're indexing servers other people already stood up.

The practical distinction is contracts: a public registry listing is one undifferentiated view of a server, visible to whoever finds it. An Elva-hosted server can expose a narrower, audience-scoped contract per consumer — an agent contract gets typed outputs and mandatory descriptions, a partner contract gets a different tool subset entirely — and a breaking change to a tool's schema blocks the publish instead of silently reaching an agent mid-conversation, the same discipline production MCP serving requires. That governance layer is the part public discovery, by design, doesn't have: a directory's job is to be found by anyone, and a company's own API gateway's job is the opposite — to be called only by whoever it decided should call it.

So: if the question is "where do I find MCP servers built by other people," start with the official registry for provenance and Glama or PulseMCP for breadth, and treat every listing the way you'd treat an unaudited package. If the question is "how do I make my own API discoverable and safely callable by agents," that's not a marketplace problem at all — that's what Elva does.

Practical guidance for a team deciding

A few questions cut through most of the "which platform" confusion faster than a feature comparison:

• Are you publishing or consuming? Consuming someone else's tools points you at a registry or an integration platform like Composio or Zapier MCP. Publishing your own API as tools points you at hosted, governed serving — Elva, Docker's toolkit for containerized self-hosting, or Cloudflare Workers if you're building the gateway yourself.
• Public or private? A server meant for the open agent ecosystem belongs in a public directory, where "found by anyone" is the goal. A server that exposes production data or write access needs authentication, scoping, and logging before it goes anywhere near a marketplace listing — most internal and partner-facing MCP servers should never appear in a public registry at all.
• Hosted or self-hosted? Docker's Toolkit and Cloudflare's Workers path both give you real infrastructure control if a platform team wants to own the runtime. A hosted option removes that operational surface in exchange for less control over where the server actually runs — worth it for most teams whose core product isn't infrastructure.
• Governed or open? The single question that predicts the most future pain: if a tool's schema changed tomorrow, would anyone notice before an agent did? If the honest answer is no, that's a governance gap, not a discovery gap, and no marketplace listing fixes it.

Most teams end up doing both — pulling a handful of vetted third-party servers from a registry for things like Slack or GitHub, and standing up their own governed MCP server for the API that's actually their product. Confusing the two, or assuming a marketplace listing is the same thing as a safe integration, is the mistake this whole landscape makes easy to make.