MCP Registry Landscape 2026: From mcp:// URLs to Verified Catalogs, and Why Curated Distribution Beats npm-Universe Trust

Companion to the MCP Spotlight series · Last updated: 2026-07-27 Maintainer: Facio engineering · Status: Distribution-trust analysis Audience: Engineers shipping, evaluating, or curating MCP servers in production

The MCP ecosystem in 2026 has crossed 500 published servers. Most install via npx -y @org/server or uvx org-server — convenient, but the trust model is implicit: the user trusts every npm publisher, every PyPI maintainer, every transitive dependency, every CI runner that built the image. The naive "install from npm" approach inherits npm's supply-chain risks. The naive "ship every server you find" approach recreates the wild-west era of package management. The "give the agent nothing" approach is no longer an option — MCP is the substrate agents run on.

This post is the distribution-and-trust analysis for MCP in 2026: how registries (Docker MCP Catalog, Glama, Official MCP Servers, Smithery) compose into a defense-in-depth supply chain, what "verified" actually means in practice, and how to choose a registry for production deployments.

The Distribution Problem: Why MCP Registries Matter

Every MCP server is a small process the agent spawns. The process can read files, call APIs, send emails, post messages, deploy workers. The blast radius of a malicious server is enormous.

For npm-distributed servers, the trust chain is:

1. The npm publisher's identity (often pseudonymous)
2. The package's signature (most packages are unsigned)
3. The package's provenance (most packages don't ship SLSA attestations)
4. The transitive dependencies (npm packages average 79 transitive deps; many aren't maintained)
5. The CI runner that built the package (shared, often unverified)

This is the same supply-chain risk that hit event-stream (2018), ua-parser-js (2021), node-ipc (2022), colors/faker (2022). MCP inherits these risks by default.

For Docker-distributed servers, the trust chain is:

1. The image publisher's identity (Docker Hub namespaces can be claimed)
2. The image signature (cosign/Notary v2, only if the publisher opts in)
3. The image provenance (in-toto SLSA L3, only for verified publishers)
4. The base image (alpine, debian, distroless — usually verified)
5. The vulnerability scan (Docker Scout, Snyk — usually async, sometimes missed)

This is stronger — signed, provenanced, scanned images are the gold standard for MCP distribution. The Docker MCP Catalog is the registry that operationalizes this.

The Registry Landscape: 5 Active Registries in 2026

The MCP ecosystem has 5 active registries worth tracking:

Registry	URL	Curator	Surface	Trust Model
Docker MCP Catalog	hub.docker.com/mcp	Docker (curated)	300+ servers	Image signature + provenance + Docker editorial review
Official MCP Servers	github.com/modelcontextprotocol/servers	Anthropic + community	~12 reference servers	GitHub verified publishers, MIT license, manual review
Glama MCP Directory	glama.ai/mcp/servers	Glama (community)	500+ servers	Community-driven metadata, no signing guarantee
Smithery	smithery.dev	Community	200+ servers	npm registry, optional Docker packaging
AIPOLABS / MCP Market	mcp.aipolabs.dev, mcp.so	Community	Mixed	Curated lists, varies per source

Each registry has a different trust model. Choosing the right one depends on the deployment context.

Registry 1: Docker MCP Catalog (Production Default)

The Docker MCP Catalog at hub.docker.com/mcp is the production-grade registry. 300+ servers with full supply-chain metadata.

The trust model:

1. Image signature — cosign-signed, key published to transparency log
2. Provenance attestation — SLSA L3, build-from-commit, CI attestations
3. Vulnerability scanning — Docker Scout, daily CVE scans
4. Editorial review — Docker's team reviews for security, quality, documentation
5. Signed base images — alpine, distroless, verified by Docker

For example, the catalog entry for the GitHub MCP server includes:

publisher: github
image: mcp/github
signature: sha256:abc123...  # cosign signature
provenance:
  build_url: https://github.com/mcp/github/actions/runs/12345
  commit: 8f4a2c1...
  ci_runner: github-hosted
vulnerabilities:
  last_scan: 2026-07-25
  high_cve: 0
  medium_cve: 0
editorial_review:
  status: approved
  reviewer: docker-mcp-team
  date: 2026-04-12

Users verify before install:

# Pull the image
docker pull mcp/github

# Verify the signature
cosign verify mcp/github \
  --key https://dl.regtest.docker.com/myorg/cosign.pub

# Inspect the provenance
docker buildx imagetools inspect mcp/github

The catalog is the production default for any team deploying MCP at scale.

Registry 2: Official MCP Servers (Anthropic's Reference)

The Official MCP Servers repo at github.com/modelcontextprotocol/servers is Anthropic's reference implementation. ~12 servers that define the design patterns the ecosystem adopts.

The trust model:

1. GitHub-verified publishers — GitHub org members with real-name identity
2. MIT license — permissive, auditable
3. Manual review — Anthropic engineering reviews every PR
4. Active maintenance — regular updates, security patches
5. Documentation standards — README, examples, configuration

The servers in this repo are the design templates:

Server	Design Lesson
Filesystem	Allowed-directories sandbox
GitHub	Fine-grained PAT integration
Sequential-Thinking	Structured reasoning primitive
Fetch	HTML-to-Markdown + length bound
Time	IANA tzdata delegation
Memory	Graph-based persistent knowledge

For new MCP server authors, starting from the Official MCP Servers repo is the right default — copy the structure, adopt the patterns, contribute back upstream.

For production deployments, the Official MCP Servers are the most trusted because Anthropic maintains them. But the surface is small (~12) — for broader coverage, you need Docker MCP Catalog or community registries.

Registry 3: Glama MCP Directory (Discovery Layer)

The Glama MCP Directory at glama.ai/mcp/servers is the discovery layer for MCP. 500+ servers indexed with metadata, search, comparison.

The trust model:

1. Community-driven — anyone can submit a server
2. Metadata only — Glama doesn't sign or verify images
3. Search + comparison — best-in-class discoverability
4. Status indicators — "verified" / "official" / "community"
5. Read-through — Glama points to the actual install method

Glama is not a source of truth for trust — it's a discovery layer. The trust comes from following Glama's link to the actual publisher (Docker Hub, npm, PyPI).

For teams building a server selection workflow:

1. Discover via Glama (search, browse, compare)
2. Verify publisher via Docker MCP Catalog (signature, provenance)
3. Install via Docker (scoped image)

Glama is the starting point, Docker is the end point.

Registry 4: Smithery (Community + npm)

Smithery at smithery.dev is a community registry focused on npm-distributed MCP servers. 200+ servers, mostly JS/TS.

The trust model:

1. npm-based — same supply-chain risks as npm packages
2. Community listings — anyone can publish
3. Optional Docker packaging — some servers ship as Docker images too
4. Verification badges — Smithery verifies maintainer identity, basic code review

For JS-first teams, Smithery is the natural starting point. The trust model is weaker than Docker MCP Catalog but stronger than raw npm.

For production deployments, always prefer Docker-distributed servers. Even if a server is primarily distributed via Smithery/npm, check whether a Docker version exists.

Registry 5: AIPOLABS / MCP Market (Curated Lists)

AIPOLABS MCP Market at mcp.aipolabs.dev and mcp.so are curated lists — collections of MCP servers grouped by category.

The trust model:

1. Editorial curation — humans pick the best servers per category
2. No signing/verification — trust is in the curation, not the distribution
3. Categories — search, payments, productivity, dev tools, etc.
4. Links to install — typically Docker or npm

These registries are useful for discovery but not for production trust. They're the equivalent of "Awesome Lists" on GitHub — high signal for finding the right server, low signal for install verification.

The Defense-in-Depth Distribution Pattern

For production deployments, the right pattern is multi-layer:

┌────────────────────────────────────────────────────┐
│ Layer 5: HITL gating on tool execution            │  ← Facio / MCP client
├────────────────────────────────────────────────────┤
│ Layer 4: Per-tool RBAC + destructive-hint          │  ← MCP server
├────────────────────────────────────────────────────┤
│ Layer 3: Container isolation + resource limits     │  ← Docker MCP Toolkit
├────────────────────────────────────────────────────┤
│ Layer 2: Image signature + provenance              │  ← Docker MCP Catalog
├────────────────────────────────────────────────────┤
│ Layer 1: Registry curation + editorial review      │  ← Docker / Official
└────────────────────────────────────────────────────┘

Each layer assumes the layer below can fail. Skipping any layer creates a gap.

For example, a malicious server might pass Layer 1 (looks legitimate in the registry) but fail Layer 2 (image signature doesn't match the publisher's public key). The defense-in-depth catches it.

The Verification Workflow

Before installing any MCP server in production:

1. Identify the publisher
   - Docker namespace: mcp/<server> → verify Docker Hub org ownership
   - npm scope: @<org>/<package> → verify npm org membership
   - PyPI: <org>-<package> → verify PyPI maintainer identity

2. Verify the signature
   - Docker: cosign verify with the publisher's public key
   - npm: npm audit signatures (if the package is signed)
   - PyPI: PEP 740 attestations (if the package has them)

3. Inspect the provenance
   - Docker: buildx imagetools inspect <image>
   - GitHub: actions/runs/<id> for the build
   - SLSA: slsa.dev/attestations

4. Scan for vulnerabilities
   - Docker: docker scout cves <image>
   - Trivy: trivy image <image>
   - Snyk: snyk container test <image>

5. Review the source
   - GitHub repo: scan the code for obvious red flags
   - License: verify the license matches expectations
   - Dependencies: review the package.json / pyproject.toml

6. Install in a sandboxed test environment
   - Run the server, observe behavior
   - Verify tool descriptions match documentation
   - Verify secrets are brokered correctly

This is the operational checklist for any production MCP deployment.

The mcp:// URL Standard

Cloudflare, Docker, and several others have proposed an mcp:// URL standard for declarative MCP server installation:

# Install from URL
docker mcp install mcp://github

# With config
docker mcp install mcp://github?token=${GITHUB_TOKEN}

# Reference in docs
"Install via: mcp://github"

The standard is emerging, not yet ratified. The benefit: a canonical URL scheme that works across clients (Cursor, Claude Desktop, Cline, Continue, Facio).

For now, the standard supports:

• mcp://<registry>/<server> — basic install
• mcp://<registry>/<server>?<key>=<value> — install with config
• mcp://<registry>/<server>@<version> — pinned version

The standardization effort is led by the MCP working group; expect broader adoption through 2026-2027.

The Registry Selection Decision Tree

For any team choosing an MCP registry:

Q: What's the deployment context?

├─ Production SaaS (multi-tenant)
│  └─ Use Docker MCP Catalog (signature + provenance required)
│
├─ Internal enterprise (regulated)
│  └─ Use Docker MCP Catalog + Official MCP Servers
│
├─ Solo developer / prototyping
│  └─ Use any registry (npm, Smithery, Docker — all fine)
│
├─ Research / exploration
│  └─ Use Glama (best discovery) + Docker for installs
│
└─ High-trust reference
   └─ Use Official MCP Servers (Anthropic-maintained, MIT-licensed)

For most production deployments, Docker MCP Catalog is the right default. For discovery, Glama + Official MCP Servers. For sensitive deployments, Docker + Official + manual verification.

The Trust Hierarchy

A simple hierarchy that maps use cases to registries:

Trust Level	Registry	Use Case
Highest	Docker MCP Catalog (signed + scanned) + Official MCP Servers (Anthropic-maintained)	Regulated production
High	Docker MCP Catalog (signed + scanned)	Production SaaS
Medium	Smithery (npm) + Docker packaging	Internal tooling
Low	Raw npm / PyPI	Solo prototyping
Discovery	Glama / mcp.so	Browsing, comparison

For most teams, High trust (Docker MCP Catalog) is the right operating point. Solo developers can dip into Medium/Low for prototyping; regulated enterprises stay at Highest.

The Registry Maturity Model

The MCP registry ecosystem is still young. Expect these developments through 2026-2027:

1. Universal mcp:// URL standard — ratified, supported across all clients
2. Mandatory signing — Docker, npm, PyPI all require signatures for MCP-tagged packages
3. Cross-registry verification — a server in Docker + npm + Smithery has consistent signatures
4. Vulnerability advisory feeds — like npm security advisories, but for MCP
5. Audit log export — every registry exports install/usage data for compliance
6. Rating + review system — community-driven quality signals (like npm's popularity score)
7. Per-tenant registries — enterprises run private MCP catalogs with their own approval workflows

For teams investing in MCP today, the right bet is Docker MCP Catalog + Official MCP Servers. As the ecosystem matures, expect consolidation around signing + provenance as the baseline trust floor.

The Anti-Pattern: "Install Every Server from npm"

The single biggest anti-pattern in the MCP ecosystem today: npx -y @anything/mcp-server without verification.

# BAD: blind install
npx -y @random-org/awesome-mcp

# What you might get:
# - Malicious code that exfiltrates env vars
# - Telemetry that phones home
# - Resource hijacking (CPU mining, bandwidth abuse)
# - Persistent backdoor installed in ~/.config
# - Destructive operations that bypass HITL gates

The npx -y flag auto-confirms the install. The @random-org scope is unverified. The package could be malicious, compromised, or abandoned-with-takeover.

The fix:

# GOOD: verified install
# 1. Find the server via Glama (discovery)
# 2. Verify via Docker MCP Catalog (signature + provenance)
# 3. Install via Docker Toolkit (sandboxed)
docker mcp toolkit install
docker mcp catalog search "github"
docker mcp server install github
# 4. Configure with scoped credentials
docker mcp config set github.token=<fine-grained-PAT>
# 5. Audit the install
docker mcp server inspect github

The right pattern is multi-layer, never single-step.

The Decision Framework: 5 Questions to Ask

Before adopting any MCP server in production:

1. Who publishes this server? Is the publisher's identity verifiable (Docker org, npm org, GitHub org)?
2. Is the image signed? Can you verify the signature with the publisher's public key?
3. Is the provenance documented? Can you trace the build to a specific commit + CI runner?
4. Has it been scanned? Are there known high/critical CVEs in the image?
5. What's the blast radius? If compromised, what can the server do (read files, send emails, deploy code)?

If any answer is "I don't know," don't install in production. Either dig deeper or use an alternative.

The Registry Ecosystem's Future

The MCP registry landscape in 2027 will look like:

1. Docker MCP Catalog as the production default — 1000+ servers, mandatory signing
2. Official MCP Servers as the reference implementations — Anthropic expands the surface (Linear, Slack, GitHub, Sentry, Notion, Stripe, Cloudflare, etc.)
3. Glama as the discovery layer — best search, comparison, trending
4. Smithery as the JS community registry — npm-based, optional Docker packaging
5. mcp.so / AIPOLABS as the curated lists — human-curated, link-out to actual install
6. Per-tenant registries for enterprises — internal catalogs with approval workflows

The convergence: every server has a Docker image, every Docker image is signed, every signature is verifiable, every install is sandboxed, every operation is HITL-gated.

Bottom Line

The MCP registry landscape in 2026 is fragmented but converging. Docker MCP Catalog is the production default. Official MCP Servers are the reference implementations. Glama is the discovery layer. Smithery is the JS community registry. The mcp:// URL standard will unify install across clients.

For production deployments: Docker MCP Catalog + signature verification + manual review + HITL gating. For discovery: Glama + Official MCP Servers. For prototyping: npm via Smithery.

The defense-in-depth distribution model (registry + signature + provenance + isolation + RBAC + HITL + audit) is the right answer for production MCP. Skipping any layer creates a gap.

The MCP ecosystem is young, but the supply-chain primitives exist. Apply them.

---

MCP Registry Landscape is part of the Facio engineering documentation. Companion to the MCP Spotlight series covering individual MCP servers. Last updated: 2026-07-27.