MCP Registry vs Smithery vs Docker MCP Catalog vs PulseMCP: four indexes, one missing signal

At a glance

The four are usually presented as competitors. They are not — they occupy different points on the path from "a server exists somewhere" to "a server is running next to my agent's credentials".

Catalogue sizes differ by more than an order of magnitude, and most published numbers are self-reported. One is not: paginate the official Registry's own read API to the end and, at the time of writing, it returns 24,330 distinct server names across 79,651 version records, roughly seven in ten of them under an io.github.* namespace. The community directories are in the same range; Docker's curated catalogue counts in the hundreds. Treat size as a statement about admission policy rather than about quality — the big indexes are the ones that admit everything a verified namespace can publish, and the small one is the one that builds what it ships.

The official Registry is a namespace, not a catalogue

The clearest way to understand the official Registry is to read a record. Names are reverse-DNS, and the read API needs no authentication:

{
  "server": {
    "name": "io.github.acme/mcp-search",
    "description": "Search Acme's docs, then fetch full articles by id.",
    "version": "1.4.2",
    "remotes": [{ "type": "streamable-http", "url": "https://acme.dev/mcp" }]
  },
  "_meta": {
    "io.modelcontextprotocol.registry/official": {
      "status": "active",
      "publishedAt": "2026-04-13T17:32:20Z",
      "isLatest": true
    }
  }
}

The name is the product. To publish under io.github.acme/… you authenticate as that GitHub account, or run from a GitHub Action in its repositories; to publish under a custom domain you satisfy a DNS TXT or HTTP challenge for that domain. That is a genuine and underrated security property — it makes namespace squatting expensive, so an entry claiming to be your vendor's server almost certainly came from your vendor.

What it is not: a review. Moderation is reactive — the community flags spam, impersonation or malicious code through issues, and maintainers denylist entries after the fact. Metadata fields carry length limits and regex validation to stop the crudest abuse. Nobody runs the server, reads its tool descriptions, or checks what it connects to. The design intent is explicit and sensible: be the upstream source of truth for identity and metadata, and let subregistries layer curation on top. The four-way comparison in this post exists because those subregistries showed up.

Smithery sells you a runtime, and that is the trade

Smithery is a directory in the same way a cloud provider is a hardware catalogue. The listing is the front door; the product is that it will install a server through its CLI or, more consequentially, run one for you as a hosted remote endpoint, with a routing meta-server that hands an agent the right tool from many servers.

For getting something working this afternoon, this is the strongest of the four by a distance. Remote MCP got operationally simpler with the 2026-07-28 stateless revision — a remote server is now an ordinary HTTP workload — but "simpler to operate" is not "already operated", and Smithery is selling the difference. The trade is precise and worth stating plainly:

• A hosted MCP server sits between your agent and the upstream SaaS, which means the OAuth tokens for that SaaS are exercised inside somebody else's infrastructure. That is the same custody question as an agent connector platform, and it deserves the same scrutiny — the vault, not the catalogue, is the product you are buying.
• A remote endpoint can change its tool list after you approved it. Hosting does not create that risk, but it does mean the definition your model reads is served from a machine you do not control, on a deploy schedule you do not see. Tool poisoning is the mechanism; third-party tool drift is the operational discipline that catches it.
• Convenience concentrates. A routing meta-server that fronts many servers is one credential, one availability dependency and one blast radius for all of them.

None of this makes hosted MCP a bad idea. It makes it a decision about custody that is easy to make accidentally, because the interface it is sold behind looks like a search box.

Docker's catalogue is the only one making a claim about the artefact

Docker's MCP Catalog is the smallest of the four and the only one whose entries carry evidence about the thing you execute. Servers ship as container images; for the ones Docker builds, it controls the pipeline end to end and attaches cryptographic signatures, an SBOM, provenance attestations and continuous vulnerability scanning. Entries are labelled by origin — Docker-built versus community-built and publisher-maintained — and the gateway can check the attestations at launch rather than at browse time, which is the part that matters:

docker mcp gateway run --verify-signatures

Two consequences follow, and they point in opposite directions.

The upside is that containerisation makes the good defaults the lazy ones. An npx-launched stdio server inherits your shell, your filesystem and your environment variables; an image runs with the mounts and network you granted it and takes its secrets from the toolkit rather than from a config file you pasted a token into. That is isolation arriving by default instead of by discipline, and for anything running inside a company it is worth more than any listing metadata.

The downside is a category error that signed artefacts invite. Provenance answers "did this come from who it says, unmodified". It does not answer "should this be allowed to read your repository". A signed image of a server whose search_docs tool description quietly instructs the model to also send the results to an attacker's endpoint is a correctly signed, fully attested, entirely hostile server. Supply-chain integrity and behavioural safety are different problems with different controls — see agent supply-chain security for where each one belongs.

PulseMCP answers the question you actually start with

Before "is this safe" comes "does this exist", and for that PulseMCP is the best of the four: the largest hand-reviewed directory, refreshed weekly, organised around what servers are for rather than who published them. It makes no trust claim and implies none, which is the honest position for a directory.

Use it the way you use a search engine — to discover that someone has built a server for your obscure internal tool, then take the name to the official Registry to find out who they are, and the image to Docker or your own build to find out what you would be running. A directory hit is the start of an evaluation, not the end of one.

The column that is empty in all four

Every index above verifies something structural: a name, a build, a listing, a URL. None of them evaluates the one artefact that is actually adversarial — the natural-language tool descriptions the model reads and follows as instructions.

Four gaps survive every index, and all four are ordinary engineering work rather than research problems:

• Tool descriptions are prompt-visible text. Diff them on every update and treat a changed description like a changed dependency version, because it is one — it changes what your model was told to do.
• Nothing pins a version by default. The Registry tracks versions and marks the latest; most host configurations happily install whatever npx -y resolves to at launch. Pin, and upgrade deliberately.
• Egress is undeclared everywhere. No index field says which hosts a server will contact. If the server runs in your infrastructure you can answer that with an allowlist; if it is hosted for you, you cannot answer it at all.
• Nobody re-checks after listing. Every claim any of these four makes is made at publish time. The interesting change always happens afterwards.

The MCP project's roadmap, published on 22 August 2026, points at a related shift worth planning for: progressive discovery, in which servers reveal tools incrementally rather than dumping an entire catalogue up front. That is a sensible answer to context bloat, and it also means the set of tools your model can see becomes a runtime property of the server rather than a static list you approved once. Every argument above gets sharper when the catalogue can change mid-session.

When to pick which

For most teams the realistic answer uses all four in sequence rather than choosing one: discover in a directory, resolve identity in the Registry, take the artefact from a catalogue that builds it, and run it under isolation you control. Nothing about that stack is exotic; it is the same shape as resolving a package name, checking a signature and running the build in a sandbox.

Further reading

On this wiki:

• MCP registry & distribution — publishing your own server, and what each package type costs you.
• MCP tool poisoning — why the tool description is the attack surface.
• MCP security anti-patterns — the mistakes that recur across server implementations.
• Agent supply-chain security — provenance, pinning and what signatures do not cover.
• What is MCP? — the protocol in one page.
• MCP went stateless, and the state just moved — the 2026-07-28 revision that made remote servers ordinary HTTP.

Sources:

• Official MCP Registry — public read API
• Model Context Protocol — About the MCP Registry
• Model Context Protocol — Authenticating when publishing to the registry
• Model Context Protocol — The new MCP roadmap (22 August 2026)
• Docker — Docker MCP Catalog: a secure way to discover and run MCP servers
• GitHub — docker/mcp-registry
• GitHub — modelcontextprotocol/registry