MCP Registry: how to audit a server before putting an agent into production

The official MCP server catalog is still in preview, with the API frozen at version 0.1 since October 2025. Before plugging a Registry server into a production agent, it's worth running the checklist the project itself provides.

The official MCP server catalog is still in preview, with the API frozen at version 0.1 since October 2025. Before plugging a Registry server into a production agent, it's worth running the checklist the project itself provides.

Why audit before plugging into the agent

The MCP Registry (modelcontextprotocol/registry) describes itself as "an app store for MCP servers": a centralized list that MCP clients can query to discover servers. It's a community project maintained by the Registry Working Group, currently led by Radoslav Dimitrov (Stacklok), alongside Tadas Antanavicius (PulseMCP), Bob Dickinson (TeamSpark), and Preeti Dewani (Ravenmail).

Two status milestones matter for anyone planning to trust this catalog in production. The registry moved out of an internal phase and into public preview on September 8, 2025, via an announcement post. On October 24, 2025, the API went into a freeze at v0.1: the project promises stability "for at least a month" while integrators test, but makes clear that the freeze applies only to v0.1, and that development of v0 (and later v1, which does target GA) continues in parallel.

In short: you're consuming a catalog that can still reset data, doesn't yet have a GA, and whose API is stable only within the announced freeze window. That changes what "validating a server" means here: it's not enough to read the catalog description, you need to audit the manifest, the publisher's provenance, and run the server in isolation before trusting it inside a real agent.

Step 1: spin up the registry locally before trusting the public one

The first move is not to audit directly against the public API. The repository itself publishes ready-made Docker images, so you can inspect the registry's behavior (and, by extension, the metadata it exposes about a server) in an isolated environment before pointing anything at production.

# Spins up the full registry with PostgreSQL (ephemeral data, resets on every restart)
make dev-compose

# Alternative: ready-made image, automatically published to GHCR
# Warning: this image does not bundle PostgreSQL. You need to run your own
# Postgres and point the registry to it via MCP_REGISTRY_DATABASE_URL
# (see the repository's docker-compose.yml for a working example)
# before running the command below.
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:v1.0.0

The project's own documentation is explicit about this alternative image: it "does not bundle PostgreSQL, so you need to run your own and point the registry to it via MCP_REGISTRY_DATABASE_URL" (see docker-compose.yml for a working example). The documentation doesn't detail what happens if the registry is started without that variable set and without a Postgres of your own pointed to it; the safe path is to make sure the database and the variable are in place before running the command above.

By default, make dev-compose seeds the local environment from a filtered subset of the production API itself, to make sure the seed reflects data that passes real validation. If you want to work offline, without hitting production, there's an explicit shortcut, but it turns off schema validation:

MCP_REGISTRY_SEED_FROM=data/seed.json MCP_REGISTRY_ENABLE_REGISTRY_VALIDATION=false make dev-compose

This detail matters: running with MCP_REGISTRY_ENABLE_REGISTRY_VALIDATION=false is great for development, but it proves nothing about the quality of a real manifest. If the goal is auditing, validation needs to be turned on.

Step 2: verify who published it, not just what was published

Here's the part that surprises people coming from registries like npm or PyPI the most: a Pull Request in this repository, adding a server.json, a server directory, or an entry in data/seed.json, does not publish anything. The documentation is explicit: even if the PR is accepted and merged, that doesn't list the server in the real catalog. Actual publishing happens through a different path, outside the registry's GitHub.

Whoever publishes uses the official CLI, mcp-publisher, and needs to prove ownership of the namespace being claimed:

# Builds the publishing CLI from the repo itself
make publisher
./bin/mcp-publisher --help

Proof of namespace ownership follows specific rules, and this is where the useful part for auditing lies: a io.github.<usuario>/<servidor> namespace can only be published by whoever is logged in as that user on GitHub (via OAuth) or running inside a GitHub Action in that user's repository (via OIDC). A custom-domain namespace, such as me.adamjones/<servidor>, requires proof of domain ownership via DNS or HTTP verification. In practice, this works as a minimal stamp of trust: before trusting a server, it's worth checking whether its namespace matches a real, verifiable identity, not just a freely chosen name.

Step 3: run the manifest's own schema validation

The repository keeps, inside pkg/model/, the data models that describe the expected structure of a server.json, and inside internal/validators/, the logic that checks whether a manifest meets that structure. There are also dedicated scripts in tools/validate-*.sh just for schema validation. The command that ties all of this together (lint, schema validation, and all tests) is a single one:

make check

It's worth running this command against the server.json of the server you intend to use, even if it's already listed in the public catalog: being listed today doesn't guarantee the manifest stays valid tomorrow, especially while the project is still in preview and subject to schema changes before GA. If make check fails, you already have the first documented stumble before putting the server in front of an agent.

Step 4: run isolated with an MCP client before the real agent

The manifest validated in the previous steps answers "who published this" and "does the manifest follow the expected schema," but it doesn't, on its own, answer "what does this server actually do when called." What a server actually exposes at runtime (tools, resources, prompts) may or may not exactly match what the manifest promises, and that can only be confirmed by running the real server.

The path I'd follow, before any promotion to production, is to run the server in isolation with a test MCP client, observing which tools it actually exposes and with what parameters, comparing that against what the manifest promises. Only afterward, with that observed behavior in hand, would I plug the server into a real agent, preferably in a staging environment that reproduces the same calls the agent would make in production.

The stumbling blocks you'll run into

In a project still in preview, with the API in a partial freeze, some problems are practically guaranteed along the way:

• Version with a broken schema: since the freeze only covers the v0.1 API, and development of v0/v1 continues in parallel, a server.json validated today can fail make check after a schema change; running validation again before every deploy avoids surprises.
• Poorly declared permission scope: the responsibility for correctly declaring the tools falls on whoever published the server; a valid manifest is no guarantee that the capabilities list is complete or up to date.
• No formal artifact-signing mechanism: the documentation describes proof of namespace ownership (OAuth, OIDC, DNS, HTTP), but doesn't detail a cryptographic signing mechanism for the published package itself; trust, today, rests more on "who owns the name" than on "the binary wasn't altered after publishing."
• Data that resets: local environments spun up with make dev-compose use ephemeral storage and restart clean every time, so any regression test needs to be reproduced, not just run once.

What remains open

The project is still heading toward a GA, and the documentation itself treats v0.1 as a temporary freeze to gather feedback, not as the final version of the API. That means the audit roadmap described here, running it locally, checking the namespace, validating the schema, isolating it with a client before the agent, tends to remain necessary until the registry formally adopts stronger artifact-verification mechanisms. Until then, treating the catalog as a starting point, not a ready-made stamp of trust, is the difference between an audited MCP server and one that's merely listed.