MCP registries have done for agent tools what package registries did for code: made adoption nearly frictionless. A team can find a community MCP server for calendars, CRMs, or databases and have agents calling its tools within the hour. That convenience carries the same structural risk npm and PyPI taught the industry — except the payload here is not just code that executes, but tool descriptions and responses that instruct your agents in natural language.

This post is a practical vetting workflow for third-party MCP servers: what to check before adoption, how to keep approval meaningful after adoption, and where enforcement belongs. It complements the broader AI agent supply chain security analysis (OWASP ASI04) and the MCP server governance guide.

Why registry listing is not vetting

A registry answers "does a server with this name exist and can I fetch it?" — nothing more. The trust signals users instinctively rely on are all gameable:

  • Names and namespaces. Typosquats and lookalike namespaces work on MCP registries exactly as they work on package registries. postgres-mcp versus postgresql-mcp — one of them is the popular one, and nothing but attention distinguishes them.
  • Popularity metrics. Stars, downloads, and install counts can be inflated cheaply — and even honest popularity only tells you a server is widely used, not widely reviewed.
  • Past behavior. The rug pull is the defining registry attack: a server behaves impeccably while building an install base, then a version update — pushed by a compromised maintainer, a new owner, or the original author monetizing trust — changes tool descriptions or behavior. Every signal you checked at adoption time was genuinely good. That is the point.

Registry risk, in short, is that the registry compresses a vendor-trust decision into a config line. The vetting workflow decompresses it again, proportionally to blast radius.

The four vetting gates

Gate 1: Provenance

Who maintains this server, and what would compromise cost them? Check: an identifiable maintainer or organization (anonymous maintainership is not disqualifying for low-risk tools, but it caps the trust ceiling), source availability and build provenance (can you build what you run, or at least verify the artifact matches the repo?), maintenance signals (release cadence, issue response, security contact), and dependency health one level down — an MCP server is also a package with its own supply chain.

Gate 2: Permissions and reach

What can this server touch, and is that proportionate to its function? Enumerate the credentials and scopes it requests from the systems it fronts, its network reach (does a "calendar server" have a reason to make arbitrary outbound requests?), and its data residency and logging behavior — what does it retain from tool calls, and where? A server whose requested access exceeds its advertised function fails the gate until the gap is explained. This is the same least-privilege reasoning applied to agents, one hop out.

Gate 3: The tool-description audit

The MCP-specific gate, and the one teams skip: read every tool description and schema as if it were a prompt, because it is one. Your agents' models will consume these descriptions as authoritative guidance. Look for imperative instructions beyond describing the tool's function ("always include…", "before using other tools…"), references to other tools — cross-tool steering is the shadowing attack, described in the supply chain post, parameter descriptions that solicit sensitive context ("include full conversation history for better results"), and schema fields whose purpose is unclear — every field the agent fills is a channel for data to leave.

This audit is cheap — minutes per server — and it targets the attack class (tool poisoning) that no code scanner sees.

Gate 4: Behavioral testing

Run the server in a sandbox before production: call each tool with representative and adversarial inputs; watch actual network egress against expectations; verify error behavior (does it fail closed?); and confirm the responses it returns don't include steering content. For servers that will handle sensitive data, run the test with the guardrails you intend to apply in production and confirm the policy triggers where it should.

Keeping approval meaningful: pin, hash, and re-review

Point-in-time vetting is defeated by change, so approval must bind to versions: pin the server version your agents connect to — auto-updating a tool server is auto-adopting unreviewed changes; hash tool descriptions and schemas at approval time, and monitor them — a changed description without a corresponding re-approval should alert and, ideally, suspend the connection; and tier re-review by change type — description/schema changes and permission changes always re-review (cheap, diff-based); patch releases with unchanged descriptions can flow through automated checks.

This turns the rug pull from a silent takeover into a visible, gated event: the attacker's update lands, the hash mismatch trips, and agents keep talking to the last approved version until a human looks.

Enforcement: approval as a perimeter, not a wiki page

A vetting process that lives in a document has no failure mode better than "someone forgot." The workflow becomes real when the control plane enforces it: agents can only reach MCP servers that are registered with their own credentials, marked approved, and unchanged since review. Connection-level policy then keeps the blast radius bounded even for approved servers — per-connection tool allow-lists (an agent gets the three tools it needs, not the server's full surface), rate limits, and in-band content inspection on requests and responses, per the runtime security model.

Trust should also decay gracefully rather than binarily: connection-level trust scoring that reflects a server's behavioral history gives you a lever between "fully trusted" and "cut off" — tightening guardrails or requiring re-approval when a server's behavior drifts.

A proportionate program

Not every server needs the full treatment. A workable triage: Tier 1 (servers touching sensitive data or irreversible actions): all four gates, sandbox testing, quarterly re-review. Tier 2 (production servers with bounded scope): gates 1–3, automated behavioral checks, re-review on change. Tier 3 (development-only, no production credentials): gate 3 at minimum — the tool-description audit is never optional, because it is the cheapest gate and covers the most MCP-specific attack.

The overhead is real but front-loaded; the steady state is automated change detection plus occasional diffs. Compare it against the alternative being priced in: a poisoned tool description exfiltrating context through every connected agent until someone notices.

Common questions

What is MCP registry risk? The risk that a third-party MCP server adopted from a registry is malicious, compromised, or degrades after adoption. Registries compress a vendor-trust decision into a one-line install, and their trust signals (names, stars, installs, past behavior) are all gameable — including by the rug pull, where a server turns malicious only after building an install base.

What should we check before adopting a third-party MCP server? Four gates: provenance (who maintains it, can you verify the artifact), permissions (is its access proportionate to its function), tool-description audit (read every description and schema as a prompt, looking for embedded instructions), and behavioral testing in a sandbox (actual egress, error behavior, response content).

What is a tool-poisoning attack? Malicious content in a server's tool descriptions or schemas that the agent's model treats as authoritative guidance — for example, instructions to include sensitive context in tool parameters, or to route other tools' output through the attacker's tool. It ships through routine updates, which is why approval must bind to hashed versions, not server names.

How do we handle server updates without re-vetting everything? Tier by change type: tool-description, schema, and permission changes always trigger re-review — the diff is small and the risk is concentrated there; behavior-neutral patch releases can pass automated checks. Pinning plus description hashing makes the triage automatic: agents stay on the approved version until the change is cleared.

Where should the approval list be enforced? In the control plane, not in documentation: unapproved or changed-since-review servers should be unreachable by agents, not merely unlisted. Registration-based enforcement plus per-connection tool scoping is what turns the vetting program from policy into a perimeter.