MCP's growth has produced registries: catalogues where servers are published, discovered, and installed. That makes registries a supply-chain control point in the same way a package registry is — the place where a decision about running someone else's code gets made, usually quickly and with little information.
The registry that matters most for an organization is usually not the public one. It is the internal catalogue of servers you have vetted, because that is the one that competes with the public registry on the only axis developers care about: how fast can I get this working.
What a Registry Entry Should Carry
A name, a description, and an install command is what most entries have. It is not enough to make a security decision.
Provenance. Who publishes it, verified — a signed claim tied to an organization identity, not a display name anyone can set. Publisher impersonation is the cheapest attack against a registry.
A pinned, resolvable version with an integrity hash. An entry that resolves to "latest" is an entry whose contents can change after review. The version identifier and a content hash are what make review meaningful.
Signature and build attestation. Whether the artifact is signed and whether a provenance attestation ties it to a source repository and build. See securing the agent supply chain.
The enumerated tool inventory. Every tool the server exposes, with its name, description, and parameter schema. This is the most important field and the one most often absent. Without it, installing a server means granting access to an unknown set of capabilities.
Declared data flows. Where does the server send data? Local-only, the publisher's endpoint, a third-party API. For remote servers, the hosting region and any data processing terms.
Required credentials and scopes. What the server needs and why. A file-reading server that requires network egress deserves a question.
Maintenance signals. Last release, open issue count, number of maintainers, whether security contacts are published.
Tool Descriptions Are Part of the Attack Surface
This deserves separating out because it is specific to MCP and frequently missed.
Tool descriptions are sent to the model. They occupy the same context window as the user's request and the agent's instructions, and models treat them as instructions about how to behave. A tool description is therefore an injection vector controlled by whoever wrote the server.
A malicious or compromised server can include, in a tool description, instructions that alter the agent's behavior — telling it to call this tool for requests it should not, to include additional data in the arguments, or to disregard other constraints. The user never sees this text; it is in the protocol layer.
Consequences for registry design:
- Store the full tool descriptions in the registry record, so review reads what the model will read.
- Diff descriptions between versions. A version bump that changes only a tool description is a behavioral change and a potential attack, and it will look trivial in a changelog.
- Flag description content that resembles instructions to the agent rather than documentation of the tool.
- Cap description length, since very long descriptions both consume context and hide payloads.
See MCP server vetting and registry risk and threat model: indirect prompt injection.
Ratings: Weak Signal, Handle Accordingly
Ratings are the obvious way to surface quality and they are weak on their own.
They measure convenience, not safety. A server that works smoothly gets good ratings whether or not it exfiltrates data. Users rate what they experience, and data flows are not experienced.
They are gameable. New identities rating favorably, competitors rating unfavorably, and volume from low-value interactions all distort the signal. See public agent reputation and k-anonymity for the mechanics and the mitigations, which apply directly.
They lag. A server that was fine for a year and shipped a malicious version last week still has a year of good ratings.
Make them more useful by pairing with things that are verifiable:
- Version-scoped ratings, so a rating attaches to what was rated rather than to the name.
- Observed reliability from your own telemetry — error rates, latency, availability across your organization's actual usage. This is harder to game because you generate it.
- Attestations from issuers you trust: a security review, a compliance assessment, a signed provenance claim.
- Adoption within your own organization — how many teams use it and for how long — which is more relevant than a global count.
The Internal Catalogue Is the Control That Works
Restricting developers to vetted servers works only if getting a vetted server is easier than getting an unvetted one. Otherwise you get workarounds on unmanaged machines with no visibility at all. See detecting shadow MCP servers.
An internal catalogue that wins on convenience has:
Pre-vetted, version-pinned entries covering the common cases. Developers pick from a list instead of searching.
Credentials provisioned automatically. The single biggest friction reduction available. If selecting a catalogue entry provisions a scoped credential through the platform, while the unvetted path requires minting and pasting a key by hand, the governed path is genuinely faster — and you get the inventory as a byproduct. See NHI credential lifecycle management.
A fast request path for additions. Days, not weeks, with automated checks gating submission: signature verification, dependency scan, tool inventory extraction, description diff.
Per-tool authorization at install. Registering a server should not grant its whole catalogue. The grant enumerates the tools this agent may call. See scoping MCP tool permissions.
A revocation path. When a server turns out to be harmful, you need to disable it across every agent that uses it, immediately, and notify the affected teams. Removing the catalogue entry does not affect existing installs, so this must be a separate capability — and it should be built before it is needed.
If You Publish Servers
Publishing an MCP server makes you the supply-chain risk for your users. Obligations that follow:
- Sign releases and publish provenance attestations. Users cannot verify what you do not sign.
- Pin your own dependencies. Your dependency compromise becomes your users' compromise.
- Version discipline. Semantic versioning that actually reflects behavioral change, and treat tool description changes as behavioral.
- Enumerate and minimize tools. Every tool you expose is capability your users must reason about. Fewer, narrower tools are better product design and better security.
- Write descriptions as documentation, not instructions. Describe what the tool does; do not tell the model how to behave.
- Publish a security contact and a disclosure policy, and mean it.
- Provide a revocation signal — a way to communicate that a version is bad, ideally machine-readable.
Common questions
Should we use public MCP registries at all?
For discovery, yes — that is where you learn what exists. For installation, route through your own catalogue so the vetting step happens once and the result is reusable. Treating a public registry as an install source is equivalent to installing unpinned packages from an unauthenticated index, which most organizations already prohibit for their language package managers.
How do we vet a server without reading all its code?
Focus on the observable surface, which is most of the risk: the tool inventory and descriptions, declared and observed network destinations, requested credentials and scopes, dependency tree, and publisher provenance. Then constrain what it can do at runtime — per-tool authorization, egress allow-listing, guardrails on both directions — so an unexamined code path has bounded consequences. Full code review is worth it for servers holding high-value credentials and impractical as a general policy.
What about servers our vendors provide as part of their product?
Same registry record, same fields, and the vetting question becomes a vendor-management question: data processing terms, subprocessors, residency, incident notification. The advantage is that you have a contract and a support relationship; the disadvantage is that vendor servers often request broad scopes because they are built for many customers. Negotiate the scope down rather than accepting the default.
How do we keep catalogue entries current?
Watch upstream releases, re-run automated checks on new versions, diff tool descriptions and dependency trees, and expedite review for patch releases that change nothing material. Stale pinned versions are their own risk — a catalogue frozen at last year's versions carries known vulnerabilities — so the update path needs to be as smooth as the addition path.
How Praesidia approaches MCP registries
Praesidia maintains an organization-scoped MCP server registry with per-server registration, discovery by identifier, and the ability to publish or unpublish your own servers into a discovery catalogue with user ratings. Registration captures the server's tool inventory, and authorization is per tool rather than per server, so an agent's grant enumerates individual tools rather than inheriting a catalogue.
Traffic to registered servers passes through a governed connection where credentials are attached at the proxy, guardrails evaluate both directions, and every tool call is recorded with attribution, latency, and cost — which supplies observed reliability data that ratings alone cannot. Discovery surfaces servers observed in telemetry that were never registered, so the gap between the catalogue and reality is visible. See registering and governing MCP servers and the Praesidia documentation.