Skip to content
T threat.cafe

· Margot Reyes (editorial persona) · Original research and datasets · on threat.cafe

The official MCP Registry has no security fields: what a registry listing does and doesn't tell you

A listing in the official MCP Registry proves two things: the publisher controlled the namespace in the server's name when it published, and, for package-based servers, that the package points back to that name. It does not prove that anyone reviewed the code. The registry's own moderation policy tells consumers to "assume minimal-to-no moderation" (MCP Registry moderation policy). The server.json schema has 11 top-level properties and none of them records a security review, scan result or risk rating. For remote servers, the registry does not even check that the publisher controls the URL.

The question the listing is being asked to answer

"It's in the official registry" has become a shortcut in approval tickets. The phrase sounds like vetting. It is discoverability.

The registry describes itself as the "authoritative repository for publicly-available MCP servers", backed by contributors including Anthropic, GitHub, PulseMCP and Microsoft (ecosystem vision). Authoritative here means canonical metadata. One of its design principles is to "avoid features that require constant human intervention or moderation" (design principles). The project pushes deeper moderation to upstream package registries and downstream subregistries. That is a reasonable design. It just means the listing carries less than buyers infer.

Field by field: what the schema contains

The figures below come from the draft server.schema.json in the registry repository at its 11 October 2026 commit. The ServerDetail object has 11 properties. Three are required.

Field          Required  What it tells you                       Security value
-------------  --------  --------------------------------------  ---------------------------------------
name           yes       Namespaced ID, e.g. com.example/x        Namespace control at publish time
description    yes       Publisher's own text                    None; self-declared
version        yes       Unique per publication, immutable       Lets you pin an exact record
title          no        Display name                            None; can imitate any brand
repository     no        Source URL, optional subfolder           Lets you inspect code, if present
websiteUrl     no        Publisher's site                        None on its own
icons          no        Images                                  None
packages       no        npm, PyPI, NuGet, Cargo, OCI, MCPB refs  Package ownership check; optional hash
remotes        no        Remote endpoint URLs and headers         None; URL control not verified
_meta          no        Publisher-provided, max 4 KB             None; self-declared
$schema        no        Schema version                          None

The registry adds its own metadata to API responses: status (active, deprecated or deleted), publishedAt, updatedAt and isLatest (official registry requirements). A deleted status is the only signal in the data that a moderator acted.

Inside packages, one field has integrity value. fileSha256 is "required for MCPB packages and optional for other package types", and when present, MCP clients "must validate the downloaded file matches the hash before running packages." The schema notes that "authors are responsible for generating correct SHA-256 hashes." It is an integrity check on what the author published, not an assessment of it.

What each verification actually proves

The registry runs real checks. They are narrower than they sound.

  • Namespace authentication. To publish com.example/server, the publisher must prove control of example.com through DNS or HTTP. To publish under io.github.username/, they authenticate as that GitHub account (official registry requirements). This proves identity of the namespace holder. It says nothing about intent.
  • Package ownership. For npm, the registry checks that mcpName in package.json matches the server name. For PyPI, NuGet and Cargo it looks for an mcp-name: string in the README; for container images, an annotation (package types). This blocks someone from listing a package they do not control. It does not check what the package does.
  • Remote URLs. The documentation is explicit: the registry "does not verify that you control the remote URL, regardless of authentication method." A server named com.example/weather proves control of example.com, "but the Registry does not check that the remote URL is on example.com" (remote servers guide). Each remote URL can belong to only one server name.

A spot check of live records

The registry API was queried on 15 October 2026 for the first 40 latest-version records (GET /v0.1/servers?limit=40&version=latest). The API returns records alphabetically, so this slice is all reverse-domain names from ac. to ai.. It is a spot check, not a census.

Field present                  Records (of 40)
-----------------------------  ---------------
remotes (remote endpoint)            37
packages (all npm)                    3
repository                           13
no repository field                  27
status = active                      40

In this slice, 27 of 40 latest records gave a reviewer no source link to inspect, and 37 of 40 were remote endpoints, the type whose URL ownership is not verified. A full crawl may differ, particularly for io.github.* names, which often link a repository. The direction of the finding does not depend on the slice: the schema has no field where a review result could appear.

What the moderation policy removes, and what it keeps

The registry removes "illegal content", "malware, regardless of intentions", spam and non-functioning servers. It will not remove "servers with security vulnerabilities" or "low-quality or buggy servers." Removal sets status to deleted, and "the server's metadata remains accessible via the MCP Registry API" (moderation policy).

Two consequences for consumers:

  • Default listings hide deleted servers. The API returns them only with include_deleted=true, which is automatic when you sync with updated_since (official registry API). If you mirror the registry, sync incrementally, or you will miss takedowns.
  • Removal is reactive. Abuse reports go to the upstream package registry and to a GitHub issue titled Abuse report: on the registry repository (FAQ). Nothing in a listing shows that a report is pending.

The checklist: what a listing proves and what you still have to check

A listing PROVES                                    You must STILL CHECK
--------------------------------------------------  ---------------------------------------------------
Publisher controlled the namespace at publish time  Who that publisher is, and whether it is the vendor
Package points back to the server name (packages)   What the package does; known-bad status per version
This version string is immutable in the registry    Whether the package or remote changed since approval
Status is active (not yet removed)                  Whether a report is pending; deleted entries if mirroring
                                                    Remote URL is on the publisher's own domain
                                                    Repository exists and matches the published artifact
                                                    fileSha256 present, and your client validates it

Turning a listing into an approval record

If your team approves servers found in the registry, record the registry's facts and your own checks side by side, so a later reviewer can see which is which. Take the server name and exact version, not "latest". Fetch that version's record from GET /v0.1/servers/{serverName}/versions/{version} and store it with the approval. Note whether repository is present and whether it matches the package or remote you will actually run. For packages, record the registry type, identifier and version, and run your known-bad check against those. For remotes, record the URL's domain and compare it with the namespace domain. Re-fetch the record at each review to see whether status has changed.

The version immutability row deserves care. The registry says a version string "cannot be changed" once published (versioning). That freezes the metadata record. A remote server's behaviour behind its URL can change at any time without a new registry version.

Limits and what would change this finding

The schema reading is exact for the 11 October 2026 commit; the registry is in preview and "breaking changes or data resets may occur." The 40-record slice is alphabetical and small. A security field, a signed attestation of review, or URL-ownership checks for remotes would each change the "doesn't tell you" column, and this piece should be re-read if any ships.

The decision consequence is simple. Treat registry presence as an identity hint for discovery, then run the same known-bad, provenance and review checks you would run on any unknown artifact. The threat.cafe board tracks MCP servers alongside packages and skills if you want a known-bad check that covers listings.

Sources

#mcp-registry #mcp-servers #trust-signals #vetting #dataset

All posts