# 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?

**Short answer:** It proves who was allowed to publish the listing, not that the server is safe. A name like io.github.alice/weather can only be published by someone who signed in as the GitHub user or organization alice, and com.example/weather only by someone who proved control of example.com with a DNS TXT record or a key file at /.well-known/mcp-registry-auth. For packages, the registry also checks at publish time that the package names the same server: mcpName in an npm package.json, an mcp-name line in a PyPI, NuGet or Cargo README, an annotation on a Docker image, or a SHA-256 hash for an MCPB file. That's the whole guarantee. The registry leaves security scanning to npm, PyPI, Docker Hub and to downstream marketplaces. Its moderation policy tells consumers to assume minimal to no moderation and says it won't remove servers that have security vulnerabilities. A GitHub namespace proves control of an account, not that the account belongs to the company it's named after. And in the registry's published validation code, a remote URL only has to be https and not localhost; nothing we found ties its host to the namespace. So confirm the namespace belongs to the publisher you expect, check the listing's status, install a pinned version, and look at what the server actually serves before your agent calls it.

## Checklist
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.

## Ask Rightshold (free, no key)
Add the MCP server https://www.rightshold.com/mcp to Claude, Cursor, ChatGPT, Grok or VS Code (one-click setup: https://www.rightshold.com/start?ref=seo), then ask: "I'm about to install an MCP server listed in the official MCP Registry. Here is its remote URL. What does it serve right now, has that changed from what was recorded, and does any tool definition carry hidden text?"

```json
{
  "tool": "precall_check",
  "arguments": {
    "url": "<the server's https remote URL from its registry listing>"
  }
}
```
- Free, no key. Checking a server doesn't register it: an unregistered server is probed for this answer only, and the answer says so.
- name_collision_check lists names on Rightshold's public record that read like a given name (exact after normalization, separators added or removed, or one name a prefix of the other). It compares only with Rightshold's record, not with the MCP Registry.
- check_listing answers whether a package hash, endpoint or store slug is on record in the Rightshold Store, or revoked there.

_Rightshold doesn't operate or mirror the official MCP Registry and can't confirm who controls a namespace. precall_check reports what an endpoint serves and what Rightshold has on record about it; it doesn't review a server's code or packages, and an unchanged answer isn't a finding that the tools are safe._

## Sources
- [MCP Registry: About (Trust and Security: namespace authentication, security scanning, not for direct use by hosts)](https://modelcontextprotocol.io/registry/about)
- [MCP Registry: How to authenticate when publishing (GitHub, DNS and HTTP namespaces)](https://modelcontextprotocol.io/registry/authentication)
- [MCP Registry: Supported package types (ownership verification per package type)](https://modelcontextprotocol.io/registry/package-types)
- [MCP Registry: Moderation policy (assume minimal-to-no moderation; status deleted)](https://modelcontextprotocol.io/registry/moderation-policy)
- [MCP Registry: Versioning published MCP servers (latest marking)](https://modelcontextprotocol.io/registry/versioning)
- [MCP Registry: FAQ (version metadata is immutable)](https://modelcontextprotocol.io/registry/faq)
- [modelcontextprotocol/registry: internal/validators/utils.go (IsValidRemoteURL, checked Nov 9, 2026)](https://github.com/modelcontextprotocol/registry/blob/main/internal/validators/utils.go)

## Related
- [How to vet an MCP server before installing it](https://www.rightshold.com/answers/how-to-vet-an-mcp-server-before-installing-it)
- [How to verify npm provenance for an MCP server package](https://www.rightshold.com/answers/how-to-verify-npm-provenance-for-an-mcp-server-package)
- [How to pin MCP server versions and review changes before upgrading](https://www.rightshold.com/answers/how-to-pin-mcp-server-versions-and-review-changes-before-upgrading)
- [Naming your MCP server so it isn't mistaken for a lookalike](https://www.rightshold.com/answers/how-to-name-your-mcp-server-so-it-isnt-mistaken-for-a-lookalike)

_Not legal advice. Updated 2026-11-09. JSON: https://www.rightshold.com/answers/what-does-a-verified-namespace-in-the-official-mcp-registry-prove.json_