There are two questions you can ask about any tool an AI agent might use, and the Model Context Protocol ecosystem has quietly decided to answer them in two different places. The first is does this server exist, and where do I find it? The second is should I trust the code enough to hand it my credentials and my filesystem? The official registry answers the first and, by explicit design, refuses to answer the second.

That refusal is the most important architectural fact about how MCP servers ship in 2026, and almost nobody frames it that way.

The registry is a listing, not a warehouse#

The official MCP registry (registry.modelcontextprotocol.io) launched in preview on September 8, 2025, and has since settled into an API freeze at v0.1 — stable enough to build against. It is backed by the names you would expect: Anthropic, GitHub, Microsoft, and PulseMCP. Read the about page and the metaphor it reaches for is "app store." A better one is phone book.

Because here is what an entry actually contains: a name, a description, and a pointer — to an npm package, a PyPI or NuGet distribution, or an OCI image. The registry stores metadata. It does not host a single byte of executable server code. When your client resolves an entry, it turns around and pulls the artifact from wherever the entry points, and that host — not the registry — decides whether the thing you just ran is signed, pinned, scanned, or none of the above.

The registry tells you a server exists. It says nothing about whether you should trust it. That gap is not a bug; it is the seam the rest of the ecosystem is now building into.

This is a defensible choice. A central code host for every MCP server would be a single point of failure, a moderation nightmare, and a bandwidth bill nobody wanted to own. Punting distribution to existing package registries let the catalog launch fast and stay neutral. But punting distribution is punting trust, because integrity lives with the artifact, not the listing.

OCI is a bet that trust is already solved#

If distribution is where trust lives, the interesting question becomes: which distribution channel already has a trust story? npm and PyPI are frictionless — npx some-mcp-server is one line — but they hand mutable, typically unsigned, unsandboxed code straight into the agent's trust boundary. The install-on-run convenience that made them ubiquitous is exactly what makes them a poor place to keep the keys.

Docker's answer is to route MCP distribution through an OCI registry, and the tell is how little new machinery it required. As of Docker Desktop 4.56 the MCP Catalog itself ships as an OCI artifact, and teams can publish their own curated catalogs with a handful of commands:

Profiles — a captured set of servers, tool selections, and client assignments — follow the same push/pull pattern from Desktop 4.63. Because a catalog is an immutable OCI artifact, you can pin production agents to acme/tools@sha256:… while QA rides a newer tag, with no drift between them.

The point is not the CLI. The point is what comes free once an MCP server is an OCI image. Cosign signing and provenance work unchanged. Vulnerability scanning applies. Policy engines like OPA can gate what an agent is allowed to pull. Registries you already operate — Harbor, Artifactory — hold the artifacts under the access controls you already wrote. Docker's own framing is that OCI-based catalogs are "the only approach that makes catalogs and agents first-class infrastructure fully addressable with GitOps tooling."

The quiet consequence: tool governance is now container security#

Stack those two facts and the conclusion is larger than any one vendor's tooling. If discovery lives in a neutral metadata registry and distribution lives in an OCI registry, then governing which tools your agents may run stops being a new discipline and becomes a subset of the container supply chain you already run. The SBOM, the signature policy, the scan gate, the digest pin — the same controls, pointed at a new kind of workload. That is a genuinely good deal for anyone who has already paid the cost of container security, and it explains why the enterprise MCP conversation (JFrog, Harbor, Docker's private catalogs) converged on OCI so fast.

There is a bill, and it is worth naming. This re-centralizes an ecosystem whose original charm was that anyone could stand up a server over stdio and hand you an npx line. Signable, pinnable, sandboxed artifacts are strictly better for a bank and strictly more friction for a hobbyist gluing two tools together on a Saturday. The runtime story softens the edge — Docker runs each server in a sandboxed container with explicit network policy and filesystem isolation, and dynamic mcp-find / mcp-add discovery pulls servers just-in-time so unused tools stay out of the model's context — but the trade is real.

So when you read that MCP has a "registry," hold the word loosely. There is a registry for knowing what exists, and there is a separate, older, harder machine for deciding what to trust. The interesting engineering of the next year is entirely in the second one.