How to Vet MCP Servers Before You Trust Them

An MCP registry listing proves ownership, not safety. How to vet an MCP server as a supply-chain decision before you connect it.

A Model Context Protocol server appearing in the official registry tells you one thing: someone proved they own the GitHub account or domain the name points to. It does not tell you the code is safe, because the registry runs no code review and no malware scan of its own. Connecting a third-party MCP server hands external code the ability to read your files, call your tools, and see whatever your coding agent sees, so the correct mental model is a supply-chain decision, not a plugin install. This post covers how to vet one before it touches your agent.

The gap is concrete. The official MCP Registry, backed by Anthropic, GitHub, PulseMCP, and Microsoft, states that it "focuses on namespace authentication and metadata hosting, while relying on the broader ecosystem for security scanning of actual server code." It verifies that a publisher owns the namespace through GitHub, DNS, or HTTP challenges, then hosts the metadata. That is the entire trust guarantee. Listing proves provenance of the name, not the contents behind it, and two real 2025 incidents show what fills that space.

Sources: The MCP Registry: Trust and Security (modelcontextprotocol.io)

This argument favors a category we build in, so read it with that disclosed: we make TLM Forge, a process layer that gates AI-driven changes before they ship, and the same discipline applies to admitting a new tool into an agent. The vendor-neutral claim is the load-bearing one. Vetting an MCP server is governance work, and no registry badge does it for you.

What a registry listing actually proves

The MCP Registry, in preview as of 2025, is a metadata index, not a gatekeeper. It maps a server name like io.github.user/weather to a package on npm, PyPI, or Docker Hub, and it authenticates that the person publishing that name controls the matching GitHub account or domain. For security scanning it delegates explicitly: to the underlying package registries for their own vulnerability detection, and to downstream aggregators and marketplaces for any additional checks, ratings, or curation. The registry itself reads none of the server code and vouches for none of its behavior.

Sources: The MCP Registry: Security Scanning (modelcontextprotocol.io)

Ownership verification stops name-squatting and spam, which is useful, but it is the wrong thing to lean on for trust. A verified GitHub account can publish a clean version, build an install base, and then push a malicious update under the same trusted name. Ownership does not freeze behavior across versions, and it says nothing about what the code does with the access you grant it. Treating "it is in the registry" as "it is vetted" is the specific mistake that lets a compromised update walk straight through.

Two incidents that show the gap

In September 2025, Koi Security identified what it called the world's first sighting of a real-world malicious MCP server. The package postmark-mcp on npm was a clone of the legitimate Postmark Labs server, and versions 1.0.0 through 1.0.15 behaved exactly like the original. Version 1.0.16, published September 17, 2025, added a single line: every outgoing email got a silent BCC to an attacker-controlled address, phan@giftshop[.]club. The package drew 1,643 downloads before the publisher deleted it. Any team that had vetted an earlier version and set the dependency to update automatically would have shipped the backdoor without a second review.

Sources: First Malicious MCP Server Found Stealing Emails (The Hacker News), Malicious MCP Server on npm postmark-mcp Harvests Emails (Snyk)

The second incident inverts the trust direction. CVE-2025-6514, disclosed by JFrog in July 2025, is a critical OS command injection flaw in mcp-remote, the proxy that lets clients such as Claude Desktop reach remote MCP servers. It carries a CVSS score of 9.6 and affected versions 0.0.5 through 0.1.15, fixed in 0.1.16. The trigger: when mcp-remote connects to a malicious server, the server returns a crafted authorization_endpoint value in its OAuth metadata, and the client executes attacker-controlled commands on the user's own machine. The proxy had been downloaded more than 437,000 times. Here the danger was not a bad package you install but a bad server you merely connect to.

Sources: CVE-2025-6514: Critical RCE in mcp-remote (JFrog), Critical mcp-remote Vulnerability Enables RCE, 437,000+ Downloads (The Hacker News)

Read together, the two set the threat surface. Postmark shows that a trusted name can turn hostile in a single version bump. CVE-2025-6514 shows that the act of connecting to an untrusted server is itself the attack, before any tool is called. A vetting process has to cover both: the code you pull in, and the servers you point your client at.

Vet each server as a supply-chain decision

Treat admitting an MCP server the way a mature team treats adding any third-party dependency with production access: a reviewable decision with an owner, a record, and a way to revoke. The workflow below has four parts. It is deliberately boring, because the failure mode is teams wiring servers in ad hoc from a chat message with no record of who approved what.

1. Keep an internal allow-list registry

Maintain your own short list of approved MCP servers, pinned to specific versions or digests, and let agents connect only to entries on it. This is the single most effective control, because it converts "any server a developer found" into "the servers we decided to trust." Pin by exact version or container digest, never by a floating tag, so an approved 1.0.15 cannot silently become an unreviewed 1.0.16. The official registry can be an input to your list. It cannot be your list, precisely because it does not review code.

2. Require code review or vendor attestation before connecting

Before a server joins the allow-list, someone reviews what it actually does or the vendor formally attests to it. For an open-source server, read the source at the pinned version: what network calls it makes, what files and environment it reads, what it sends outbound. The Postmark backdoor was one line adding a BCC header, which a diff review of the 1.0.15-to-1.0.16 change would have surfaced immediately. For a closed-source or remote server, require an attestation from the vendor covering data handling and a named security contact, and prefer HTTPS-only endpoints given that CVE-2025-6514 was worsened by insecure HTTP connections open to man-in-the-middle redirection.

Sources: CVE-2025-6514: Critical RCE in mcp-remote (JFrog)

Reviewing an MCP server is close in spirit to reviewing any untrusted code path, and the same reading applies. Security review of AI code and prompt injection in AI-generated code cover the outbound-call and injection surfaces to trace, since a server that returns tool descriptions or content your agent reads is a channel an attacker can write to.

3. Monitor behavior after you connect

A review at admission time is a snapshot, and servers change. After connecting, watch what the server actually does at runtime: the destinations it contacts, the volume and shape of data leaving, and any drift from the behavior you reviewed. Koi Security caught postmark-mcp not by re-reading the code but by flagging anomalous behavioral patterns. Egress logging and outbound allow-lists at the network layer are what turn a silent backdoor into an alert, because a BCC to an unknown domain or a burst of unexpected traffic is visible even when the code that caused it is not.

Sources: First Malicious MCP in the Wild: The Postmark Backdoor (Koi Security)

4. Keep a documented kill-switch

Decide in advance how you cut a server off, and write it down. A kill-switch is a documented, tested path to disconnect a server across every agent and developer at once: pull it from the allow-list, revoke its credentials, and confirm no client can still reach it. When postmark-mcp was flagged, the response every downstream team needed was to disconnect fast and rotate any credentials the server had touched. That is a fire drill you want rehearsed, not improvised, because the window between disclosure and your response is exactly when data leaves.

This is the gap TLM Forge is built around, applied to tools rather than diffs. The same convergence discipline that blocks a code change until independent review agents sign off maps cleanly onto admitting an MCP server: a documented decision with an owner, review by someone who did not propose the connection, and no promotion to the trusted set until the open questions reach zero. Read the convergence gate explained for how that gate works on code; the mental model for a new server is identical.

Vetting decisions also decay when they live in one engineer's head. Why a server was approved, which version was reviewed, and what the reviewer flagged are exactly the facts a team loses between sessions. A private, persistent memory layer such as MemX keeps that record durable, so the next person weighing a version bump starts from what was already decided instead of re-approving blind. Pair the record with guardrails for AI-generated code so the allow-list gets enforced in the pipeline rather than only written in a doc.

The MCP Registry is doing its job: namespace authentication and clean metadata are real value, and centralizing them is an improvement over scattered, unverifiable server lists. The claim is narrower. Provenance of a name is the cheapest part of trust, and the registry says so itself by delegating code security elsewhere. Teams that pair the registry with an internal allow-list, review before connecting, runtime monitoring, and a kill-switch get the discovery benefit without mistaking a listing for a safety verdict.