Security scan results: 17/100 (F) for the official MCP registry server

[stevenkozeniesky02]

We're running free security audits of popular MCP servers. The official MCP registry server scored 17/100 (F) with findings across 7 tools.

Given this repo's role as the canonical registry for the ecosystem, flagging this explicitly.

Breakdown by category:

Category	Grade
Validation	F
Auth	B
Hallucination	varies by tool

The main findings are structural:

• No input schema validation on most tools. Parameters accept arbitrary strings with no constraints.
• No authentication layer detected. Any agent can call any tool.
• Tool descriptions don't specify scope boundaries, which means LLMs will assume the broadest possible interpretation of what each tool can access.

These are the same patterns we see across 72% of the ecosystem. The difference is that this server serves as a reference point for community implementations, so fixing these here has outsized downstream impact.

Full results: https://agentsid.dev/registry
Scanner is open source: npx @agentsid/scanner

[unitedideas]

Seconding the call to close the validation gap — the 72% figure matches what we see from an adjacent angle.

We run NHS (https://nothumansearch.ai), which indexes 8,639+ MCP/agent servers from awesome-mcp, PulseMCP, llmstxt, and direct crawl. One tool we ship is /score — a 0-100 readiness check that looks at 7 signals (llms.txt, openapi, ai-plugin, MCP JSON-RPC probe, robots.txt AI directives, structured API, schema.org). It is explicitly not a security audit — it is a cheap first pass that answers "is this server discoverable and well-described enough to even audit".

Example against the registry server:

curl -s -X POST https://nothumansearch.ai/api/v1/check \
  -H 'Content-Type: application/json' \
  -d '{"url":"https://registry.modelcontextprotocol.io"}'

Returns:

{"agentic_score":35,"signals":{"ai_plugin":false,"llms_txt":false,
 "mcp_server":false,"openapi":true,"robots_ai":false,
 "schema_org":false,"structured_api":true}}

The low score here is consistent with the scanner's findings — missing llms.txt and ai-plugin means there is no machine-readable scope declaration for agents to key off of, which is the upstream of the "LLMs will assume the broadest possible interpretation" problem you flagged. Structured readiness signals + input validation are complementary: the former tells agents what the server claims to do, the latter enforces it at the boundary.

Happy to run /score over a batch of ecosystem servers and share the distribution if that would be useful context for prioritizing fixes.

[rdimitrov]

Hey @stevenkozeniesky02, thanks for the heads up! A few things worth clarifying though: the official registry is a public REST API (catalog of servers), not an MCP server with tools. The scanner's findings are framed as if it were one ("tools accept arbitrary strings", "any agent can call any tool"), which doesn't really map here. Our write endpoints do require authentication (GitHub OAuth, GitHub OIDC, DNS, or HTTP domain verification), and read endpoints are public by design since this is a public catalog.

Request and response validation on our API is defined by the published OpenAPI spec and enforced in the handlers, so if there's a concrete endpoint and input that bypasses validation or auth, we'd love a specific reproduction rather than an aggregate score. Without that, there isn't anything actionable here, so going to close this out. Happy to reopen if you can share a specific finding against a specific endpoint.