Official MCP Registry: How to Check an Entry Before You Install It (Nov 2026)

The official MCP Registry proves who published an entry. It doesn't check what the server does. Before you install from it, check six things: the namespace, the packages, the remote URL, the version, reported GHSA and CVE issues, and the repo. Most take a minute each.

What the official MCP Registry checks, and what it doesn't

The official MCP Registry is the MCP project's public list of servers. Clients and directories read it to find servers. It stores metadata only. The code lives on npm, PyPI, Docker Hub or the publisher's own server. Its docs still call it a preview, where "breaking changes or data resets may occur".

When someone publishes, the registry checks two things:

• The namespace. A name like io.github.alice/weather needs a login to that GitHub account. A name like com.example/weather needs proof of example.com: a DNS TXT record or a file at /.well-known/mcp-registry-auth.
• The package. The package must point back at the registry name: mcpName in an npm package.json, an mcp-name: line in a PyPI README, an io.modelcontextprotocol.server.name label on a Docker image, or a SHA-256 hash for an MCPB file.

What it doesn't check:

• The code. Nobody reviews what the server does or which permissions it asks for.
• The remote URL. Its docs say it "does not verify that you control the remote URL", and that several server names can list the same URL.
• Known security issues. The registry doesn't flag CVEs.

So a registry entry tells you who published it. Whether you should run it is up to you. These six checks cover the gap.

1. The name and namespace: who published it?

The part before the slash says who proved control.

• io.github.<name>/...: a GitHub account. For an organization name, the registry now requires the publisher to be an Owner of that org. Open https://github.com/<name> and check it's who you think it is. io.github.neo4j-contrib/... is the neo4j-contrib org, not necessarily Neo4j the company.
• Reverse-DNS, like com.stripe/...: someone proved they control stripe.com. You can see the proof yourself:

nslookup -type=TXT stripe.com          # look for "v=MCPv1; k=ed25519; p=..."
curl https://example.com/.well-known/mcp-registry-auth   # the HTTP method

On 2026-11-12, stripe.com had the v=MCPv1 TXT record that backs com.stripe/mcp.

Watch for names that look official but aren't, like an io.github.<someone> entry with a big brand's name in the title. The title and description are whatever the publisher typed. Only the namespace is checked.

2. The packages: what will actually run?

An entry's packages list says what to install: an npm or PyPI package, a Docker image, a NuGet package or an MCPB file. That's the code that will run on your machine.

• Match the name exactly. Copy the package name from the entry, not from a search. Lookalike names are a common trick.
• Open the package page. Who maintains it on npm or PyPI? When was it last published? Is it marked deprecated? npm view <package> deprecated shows the author's own warning.
• Check the arguments and env vars. The entry lists what the server asks for. A server that wants an all-access token is a bigger bet than one that asks for a read-only key.

3. The remote URL: whose server is it?

An entry with remotes runs on someone else's server. You send it your prompts and tool calls.

• Is the URL on the publisher's domain? com.stripe/mcp lists https://mcp.stripe.com. Same company, so that fits. An io.github.<someone> entry pointing at a big company's domain does not prove that company runs it. The registry doesn't check URL ownership.
• Is it HTTPS? Don't send a token to a plain http:// URL.
• Identify the entry by name and version, not by URL. The same URL can appear under several names, each with its own headers and settings.

4. The version: what the registry lists vs. what's newest

Each entry has a version, and its packages have their own. They can differ.

• The listed version can trail the package. A publisher may ship a fix to npm or PyPI without updating the registry entry. Check the package's own latest release.
• Check the status. Entries can be active, deprecated or deleted.
• Pin what you install. Install the exact version you checked, like npx -y some-package@1.4.2, not the bare name.

Our /registry pages show this. When the registry's server version and its package version disagree, the page says so and checks the package version, because that's what gets installed.

5. Reported issues: any GHSA or CVE?

The registry doesn't track security issues, so check the packages against advisory databases.

Our /registry pages do this every night. They mirror every entry (61,326 servers and 241,494 versions on 2026-11-12) and match each package against OSV (which includes GitHub's GHSA advisories) and the NVD CVE list. Each page gives one of three verdicts:

• Hold off. A reported issue affects the version the registry lists.
• Update first. Issues were reported, but none is flagged on the listed version. Make sure you run a version past them.
• Nothing reported yet. A good sign, but not proof of anything.

Each issue also says whether the listed version is "Affected", "Not flagged" (OSV doesn't mark it as affected) or "Not checked" (the source gives no version to compare). To find entries to avoid, filter the list by Listed version affected.

You can also check by hand: search the package name on osv.dev and in the repo's Security tab.

6. The repo: does it match the package?

The entry's repository link comes from the publisher's server.json. Open it and check it's the same project: the README should name the same package, and releases should line up with the package versions. A busy repo with recent commits and answered issues is a better sign than a single commit from last year.

If we've graded the server, the /registry page links to its grade. Most registry entries have no grade.

Do all six in one prompt with registry_lookup

Our TrustedMCP MCP server has a registry_lookup tool that pulls the entry, its packages and remotes, the version, our grade if there is one, and the reported issues. We built it, so weigh that. Ask your agent:

Check the MCP Registry entry for io.github.neo4j-contrib/mcp-neo4j-cypher before I install it.

Real output from the live API on 2026-11-12:

**io.github.neo4j-contrib/mcp-neo4j-cypher** (`io.github.neo4j-contrib/mcp-neo4j-cypher`) in the official MCP Registry
A simple Neo4j MCP server that allows you to run Cypher queries against a Neo4j database.
Listed version: 0.5.1 · Runs as: pypi · Status: active · Versions tracked: 4
Package: pypi mcp-neo4j-cypher@0.5.1
Repo: https://github.com/neo4j-contrib/mcp-neo4j
TrustedMCP grade: none yet. Ask for one: https://trustedmcp.io/submit
Reported issues (2 reported issues, listed version affected):
- GHSA-x3cv-r3g3-fpg9 (also CVE-2026-35402, PYSEC-2026-2626): Neo4j Labs MCP Servers: SSRF and Data Modification via read_only Mode Bypass Through CALL Procedures [low, listed version affected, published 2026-04-17] https://osv.dev/vulnerability/GHSA-x3cv-r3g3-fpg9
- GHSA-vcqx-v2mg-7chx (also CVE-2025-10193, PYSEC-2026-1620): Neo4j Cypher MCP server is vulnerable to DNS rebinding [high, listed version not flagged, published 2025-09-11] https://osv.dev/vulnerability/GHSA-vcqx-v2mg-7chx
Page: https://trustedmcp.io/registry/io.github.neo4j-contrib/mcp-neo4j-cypher

The listed version, 0.5.1, is affected by the first advisory. Before you install it, open the advisory and check whether a newer PyPI release fixes it. The second advisory doesn't flag 0.5.1, but the page says to make sure you're past it.

A clean one looks like this:

**com.stripe/mcp** (`com.stripe/mcp`) in the official MCP Registry
MCP server integrating with Stripe - tools for customers, products, payments, and more.
Listed version: 0.2.4 · Runs as: remote · Status: active · Versions tracked: 1
Remote: https://mcp.stripe.com (streamable-http)
Repo: https://github.com/stripe/agent-toolkit
TrustedMCP grade: none yet. Ask for one: https://trustedmcp.io/submit
Reported issues: none found (last checked 2026-11-12).
Page: https://trustedmcp.io/registry/com.stripe/mcp

The tool gathers what you need for checks 2, 4 and 5: the packages, the version and the reported issues. The rest still needs a human look: who owns the namespace, whose domain the URL is on, who maintains the package, and whether the repo matches.

If you'd rather use the registry's own API, it's open:

curl "https://registry.modelcontextprotocol.io/v0/servers?search=com.stripe"

What to do with what you find

• Hold off: don't install the listed version. Look for a fixed release, or pick another server.
• Update first: install a version past every reported issue, and pin it.
• Nothing reported, no grade: do checks 1, 3 and 6 by hand, then read the config entry before you add it (how to scan your MCP config). You can ask us to grade it.
• Looks malicious: the registry's FAQ says to report it as abuse to the package registry (npm, PyPI, Docker Hub) and open an issue on the registry repo with a title starting Abuse report:.

For the wider pre-install routine, see the MCP server security checklist, whose first step, "Who publishes it?", is check 1 here. Once it's installed, other tools take over: a scanner for its tool descriptions, a gateway or approval prompts while it runs. See MCP security tools for what each one covers.

Frequently asked questions

What is the official MCP Registry?

It's the MCP project's public list of MCP servers, at registry.modelcontextprotocol.io. It holds metadata like names, versions, packages and remote URLs, which clients and directories read. The server code stays on npm, PyPI, Docker Hub or the publisher's own server.

Does the official MCP Registry check servers for security?

No. It checks that the publisher controls the namespace and the package. It doesn't review code, flag CVEs or verify remote URLs. Check reported issues yourself, or on our /registry pages.

What does io.github mean in an MCP server name?

The publisher logged in with that GitHub account, or is an Owner of that GitHub organization. It tells you which account published the entry, not that a company with a similar name made it.

How do I know a com.example name is real?

A reverse-DNS name means someone proved control of that domain with a DNS TXT record (v=MCPv1; ...) or a file at /.well-known/mcp-registry-auth. Run nslookup -type=TXT example.com or open that URL to see the proof.

Can someone list a remote URL they don't own?

Yes. The registry's docs say it doesn't verify that the publisher controls the remote URL, and several names can list the same one. Check that the URL's domain matches the namespace.

How do I report a malicious MCP server?

Report it as abuse to the package registry it uses, and open an issue on the modelcontextprotocol/registry GitHub repo with a title starting Abuse report:.

Is there an MCP registry security check I can run?

The registry itself only checks namespace and package ownership, so the security part is yours. Look up the entry's packages in OSV and the NVD, or let the registry_lookup tool in our TrustedMCP MCP server list the reported issues. It's an assessment from public signals, not a guarantee.