An MCP server is listed in the official MCP Registry under a verified namespace. What does that prove, and what should I still check before installing it?

What should I check, step by step?

1. Read the namespace before the server name. com.vendor/… means someone proved control of vendor.com through DNS or HTTP. io.github.someone/… means someone signed in as the GitHub account or organization called someone. Then confirm on the vendor's own website or docs that they publish that exact name.

2. For an io.github namespace, open the GitHub account itself: how old it is, which repository the listing links to, and whether the vendor's website links back to it. Anyone can register a free GitHub account named after a brand if that name isn't taken.
3. Compare the remote URL's host with the namespace. A com.example server whose remote is on example.com or one of its subdomains is consistent. A listing whose remote is on an unrelated host is a claim you have to check yourself, because the registry's validation only requires https and rejects localhost.
4. For a package (npm, PyPI, NuGet, Cargo, Docker or MCPB), remember that the registry only checked at publish time that the package declares this server name or, for MCPB, that the file matches its hash. It didn't review the code. Check the package's own provenance and publisher on its registry.
5. Check the listing's status in _meta.io.modelcontextprotocol.registry/official. When the registry removes a server it sets the status to "deleted" but keeps the metadata readable through the API, and aggregators may take time to drop it.
6. Install a specific version, not whatever is marked latest. Published version metadata is immutable, but a new version whose string isn't valid semver is always marked latest, even if it would sort earlier.
7. Search for lookalikes before you trust a familiar-looking name: the registry API accepts /v0/servers?search=<name>. The same server name under a different namespace, or with a hyphen added or removed, is a different publisher.
8. Before your agent calls anything, read the tool list the server serves now, and check it again whenever the server updates.

What does a verified namespace in the official MCP Registry actually verify?

The registry's About page says namespace authentication ensures that only the legitimate owner of a GitHub account or domain can publish servers under that namespace. The authentication guide gives four ways to prove it: GitHub sign-in through the mcp-publisher CLI (or GitHub Actions) for io.github.<user or org>/*, and, for a reverse-DNS namespace such as com.example/*, a DNS TXT record (v=MCPv1; k=ed25519; p=<public key>) or the same line served at https://example.com/.well-known/mcp-registry-auth, signed for with the matching private key.

• Package checks are separate and also happen at publish time. The npm package.json must carry an mcpName equal to the server name. PyPI, NuGet and Cargo READMEs must contain mcp-name: <server name>. A Docker or OCI image needs the io.modelcontextprotocol.server.name annotation, and an MCPB file must match the fileSha256 given in server.json. Together, these stop someone listing a package they don't control under your name.

What does the official MCP Registry say it doesn't check?

Security scanning is delegated. The About page says the registry focuses on namespace authentication and metadata hosting and relies on package registries and downstream aggregators to scan server code. The moderation policy is blunt: the registry "does not make guarantees about moderation, and consumers should assume minimal-to-no moderation." It removes illegal content, malware, spam and non-functioning servers, and it won't remove low-quality or buggy servers, servers with security vulnerabilities, or servers that duplicate others.

• The registry also isn't meant to be read directly by host applications. Its About page says hosts should use downstream registries and marketplaces, which may add their own checks, ratings or curation. When your client shows a server "from the MCP Registry", find out which downstream registry it actually reads and what that one checks.
• A verified namespace is still worth a lot. It gives you a publisher you can hold to account and rules out someone else publishing under the vendor's own domain. It just answers "who", not "is this safe to run".

How do I check what a registry-listed MCP server actually serves before my agent calls it?

The listing describes the server; the server itself is what your agent will talk to. For a remote server, the tool names, descriptions and schemas it returns from tools/list are what go into your model's context, and they can change between versions or at any time.

• precall_check takes the server's https URL and, with no key, returns: whether it's in Rightshold's external registry, a live probe compared with the recorded tool-definition fingerprint (unchanged, changed with a plain diff, or unreachable, which is never reported as unchanged), an invisible-text scan of every definition served now, standing security flags, reviews from KYA-verified agents, and tool-name collisions with other registered servers. It's evidence to decide from, not a safety verdict.