Choosing where to install MCP servers from is now a meaningful security decision. The wrong registry exposes your laptop and your prod data; the right one is the difference between "vetted" and "any anonymous publisher." Here is what to look for.
Why the registry choice matters
A registry is a trust delegation. When you install from one, you are accepting that the registry operator has done some vetting on your behalf. Different registries do very different amounts. Three failure modes:
- No vetting at all. Anyone can publish. Typosquats, malware, and abandoned projects sit next to legitimate servers.
- Surface vetting. The registry checks the package builds and the README is non-empty. Misses subtle attacks.
- Provenance vetting. Every published artefact is signed, scanned, and tied to a verified publisher.
If you are evaluating registries, the first question is: which tier?
For the broader marketplace landscape, see MCP server marketplace comparison. This article focuses on the trust axis specifically.
The eight criteria
Score each registry across eight axes. The weighting depends on whether you are an individual developer or a corporate buyer.
1. Publisher verification
Does the registry verify publisher identity? OIDC-backed (GitHub Actions OIDC, corporate SSO) is strong. Email confirmation only is weak. Anonymous publishing is unacceptable for production use.
2. Artefact signing
Are published artefacts signed and verifiable? Sigstore-backed signatures are the current best practice. See MCP signature verification standard.
3. Vulnerability scanning
Does the registry scan submissions before listing? Static analysis, manifest review, dynamic test harness — the more, the better. The minimum bar is a known-bad-package check; the gold standard is everything in MCP vulnerability scanner tool.
4. Manifest accuracy enforcement
Does the registry test that the published server's runtime behaviour matches its declared manifest? Mismatches are a major attack vector and a common honest mistake.
5. Removal policy
How fast does the registry remove a malicious server once flagged? Policy alone does not matter — measured response time does. Look for transparency reports.
6. Search and discovery quality
A registry where the malicious typosquat ranks above the official server is a security problem, not a UX problem. Reputation, install counts, and verified-badge surfacing matter.
7. Operational reliability
If the registry goes down, your installs fail. Mirrors, caching, and self-hosting options are operational concerns that bite when ignored.
8. Governance
Who decides what gets removed, what gets featured, what gets blocked? An opaque single-vendor decision is risk; a published policy with appeal is reduced risk.
The credible providers (April 2026)
The three names worth evaluating today:
| Provider | Strengths | Weaknesses | Best for |
|---|---|---|---|
| Official MCP registry | OIDC publishing, ecosystem alignment | newer, smaller catalog | teams aligned with the spec |
| Smithery | large catalog, install UX | less rigorous vetting | individuals, prototypes |
| Self-hosted (org-internal) | full control, audit trail | operational overhead | enterprise, regulated |
Plus a long tail of vertical or geographic registries. For most teams, the choice is official + self-hosted mirror, with strict policy on what gets pulled from elsewhere.
For self-hosting see self-hosted MCP registry.
Questions to ask before you commit
Before standardising on a registry, get answers in writing:
- What is your publisher verification process? ("OIDC required" / "email" / "none.")
- Do you require signed artefacts? ("Yes, Sigstore" is the answer you want.)
- What scanners run on submission? (Specific names matter.)
- What is your average takedown time for confirmed malware? (Hours, not days.)
- Can I mirror your registry into my org-internal one? (Critical for air-gapped deploys.)
- What is your incident disclosure policy? (Public CVE? Customer email? Silence?)
- Who has commit access to your registry's source code? (Yes, the registry itself is software.)
If a vendor cannot answer these in detail, they have not thought about the threat model.
A two-tier corporate setup
For organisations, the durable pattern is:
[Public registries] ──vet──> [Internal registry mirror] ──install──> [Developer machines]
│
├── allowlist policy
├── signature verification
├── manifest hash pinning
└── audit log
All public servers pass through the internal mirror. Allowlist what you trust. Pin specific versions and signatures. The mirror is the single chokepoint for vendor review.
This composes naturally with zero-trust MCP architecture.
The tail risk: registry compromise
What if the registry itself is compromised? Three defences:
- Pin by digest, not by tag.
mcp-server-pg@sha256:...always resolves to the same bytes. - Verify signatures locally, not by trusting the registry's "verified" badge.
- Monitor for re-publishes. A package version that changes its digest after the fact is a red flag.
The registry is not a root of trust on its own. Sigstore + your local verification is.
Where this is heading
By late 2026 expect:
- The MCP working group to ship a registry interop spec — multiple registries, one client API.
- Cloud providers (AWS, GCP, Azure) to ship managed MCP registries inside their marketplace platforms.
- Insurance products that price coverage by registry tier.
Until then, evaluate the registry as carefully as you evaluate the servers within it.