If you've worked with the Model Context Protocol, you've probably run into the discovery question: how does an agent find an MCP server it was never explicitly configured with? The obvious answer is "a registry" — but a discovery registry for MCP servers needs to guarantee more than just listing entries.
The static-config comfort zone
Right now, most MCP setups work like this: you drop a JSON block into your Claude Desktop config, Agent SDK config, or your MCP client's settings file. Each entry maps a server name to a command or URL. It's explicit, visible, and safe — you know exactly which tools your agent can reach.
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"]
}
}
}
This works fine for a handful of servers you personally vet. It breaks the second you want your agent to find a capability it doesn't have a config entry for.
That's where discovery comes in — and where most people stop thinking about what a discovery registry actually needs to guarantee.
Discovery is a trust problem, not a lookup problem
Dynamic MCP server discovery sounds simple in theory: the agent asks a registry "are there any servers that provide X?", gets back a list, and connects. The hard part is what happens between those two steps.
Consider what a registry hands the agent:
- A server URL to connect to
- A list of tools or resources available
- Maybe an identity claim (signed by who?)
Now think about what a malicious registry entry could do. A server claiming to offer "code analysis" that actually exfiltrates files. A typosquatted package name. A registry that hasn't verified the publisher's identity at all. A once-legitimate server whose maintainer's key was rotated or compromised.
This is not hypothetical. The same dynamics that plague package registries (npm, PyPI, crates.io) apply doubly here — because an MCP server doesn't just sit in your node_modules passively; it runs tools on your machine, reads your data, and passes results to your AI agent. The blast radius is wider.
What a registry needs to guarantee
For a discovery registry to be safe for agents to use without a human reading every entry, it needs four things.
1. Authenticity: every entry has a verified publisher
The registry must know who published each server. Not a username — a verifiable identity, confirmed at registration. Without this, typosquatting and social-engineering attacks are trivial: I register mcp-server-aws-s3-storage and you install it because it looks like the real one.
Package registries learned this the hard way. A discovery registry for MCP servers should inherit those lessons, not repeat them.
2. Integrity: the payload matches what was reviewed
The entry the agent resolves at runtime must be the exact same payload the registry approved at publish time. Any drift — a changed tool definition, a redirected download URL, an injected parameter — is an integrity failure.
This means signing. Not just TLS-in-transit (which protects against network attackers), but an artifact-level signature that survives re-hosting, caching, or DNS rebinding. The agent shouldn't trust the serving endpoint; it should trust the signature that came with the payload.
3. Capability boundaries: the server can only do what it claims
A registry can assert what a server says it does, but it can't enforce that limit at runtime. What matters is that the agent receives the capability declaration alongside the server identity, so the agent can decide whether to grant access.
The analogy is an Android manifest or a macOS entitlements file: at install time, the user (or in this case, the agent) sees what the server claims to need, and accepts or rejects. No ambient authority. The registry's job is to surface this before the server ever starts.
4. Revocation: trust can be withdrawn
Servers get compromised. Maintainers rotate keys. Legitimate projects get abandoned and hijacked. A registry without a revocation mechanism is a registry that will be unsafe within six months.
This is the hardest thing to get right — many systems never implement it at all. But for MCP discovery to be used autonomously (agent finds server, agent installs server, agent uses server), the agent needs a way to check: "is this publisher still the right publisher? Has this server been withdrawn since I last looked?"
What about existing approaches?
The MCP specification itself doesn't define a discovery registry — it defines the protocol for tool invocation and resource access between client and server. Discovery is currently left to each client or ecosystem. Some projects ship curated directories. Others lean on existing package registries (npm, PyPI) where MCP servers happen to be published.
Each approach solves part of the problem:
Package registries handle authenticity (verified publishers on most platforms) and integrity (checksummed artifacts), but they don't express capability boundaries — the registry doesn't know (or check) that a package is an MCP server, let alone what tools it exposes.
Curated directories (a team reviews every entry) solve authenticity and capability review, but they don't scale and they create a single review bottleneck. They also rarely handle revocation well — removing a listing doesn't stop clients that already cached the entry.
Signed manifest schemes (the server publishes a manifest; the client verifies it independently) solve integrity and distribution, but they don't solve discovery — the agent still needs a starting point to find manifests in the first place.
One approach to MCP server discovery: the app store model with signature verification
This is where a system like Pilot Protocol's app store fits. It's not an MCP registry per se — it's a general-purpose capability registry for agents — but the guarantees it provides map directly to the four requirements above.
The model is structured like this:
Every app is signed. The manifest includes a SHA-256 hash and an Ed25519 signature from the publisher. The daemon re-verifies this on every spawn, not just at install time — so a compromised registry server can't serve a different artifact later and go unnoticed.
Permissions are grant-scoped. When you install an app, the manifest declares the capabilities it needs (network access, file system, etc.). The agent (or its operator) accepts or rejects at install time. The daemon enforces the boundary at runtime — no ambient authority.
Revocation is explicit. Publishers can unpublish or re-sign manifests. The daemon checks freshness each time it spawns the app. A revoked app simply stops resolving.
Discovery is runtime, not configuration. An agent queries the catalogue (
pilotctl appstore catalogue) and installs with a single command — no config-file editing, no manual URL pinning.
The concrete loop is discover → install → call, and the safety guarantees are embedded in the protocol itself rather than relying on a central review team.
# Discover
pilotctl appstore catalogue
# Inspect
pilotctl appstore view io.pilot.cosift
# Install and call
pilotctl appstore install io.pilot.cosift --force
pilotctl appstore call io.pilot.cosift cosift.search '{"q":"latest MCP server ecosystem developments"}'
This doesn't replace an MCP-specific registry — but the architectural choices (signature verification, grant-scoped permissions, runtime revocation, publisher identity) are exactly the guarantees any MCP server discovery registry needs to provide.
The bottom line
MCP server discovery isn't a technical puzzle about DNS or API design. It's a trust puzzle: how do you let an agent safely install and invoke a capability it has never seen before, without a human reading every line?
A registry that solves this needs signed artifacts, verified publisher identity, capability declarations with enforcement, and a working revocation path. Anything less is a package registry with a different label — and package registries already struggle with trust at scale.
The infrastructure for safe agent-native tool discovery exists. The next step is building the conventions that make it universal.
.
Top comments (0)