MCP Server Scorecards

The MCP 2026-07-28 spec moved the protocol to a stateless core, removed the HTTP+SSE transport, and aligned authorization with OAuth 2.1. Hundreds of public MCP servers now silently fail it, and directories list servers without auditing any of them. Scorecards grade public servers against a published, versioned rubric, from source, at a pinned commit, with evidence for every result.

How grading works

  • Static analysis only. We read the server's public source at a pinned commit. We never probe live endpoints without permission, and nothing from a graded repository is executed.
  • Six axes, evidence-cited. Transport, stateless core, lifecycle, authorization, tool design, and security hygiene, each pass / partial / fail / n-a with the file and behavior it rests on.
  • Right to respond. Maintainers see their draft scorecard before publication and get a window to respond or fix. Exploitable findings follow responsible disclosure, never zero-day publication.
  • Commit-addressed. A scorecard describes the graded commit, nothing later. Re-grades at a new commit are one issue away.
AAll axes pass; notes may list minor hardening suggestions.
BNo fails; one or two partials.
COne non-security fail, or three or more partials.
DA security-axis fail that is not directly exploitable.
FAn exploitable finding, published only after responsible disclosure and a fix window.

Scorecards

We graded ourselves first, with the same rubric and no courtesy window: findings against our own server ship immediately. This is the registry's own catalog server, the one behind clauderegistry.com/mcp.

ClaudeRegistry Plugin Catalog

ClaudeRegistry/mcp-server@0f58245 · graded 2026-08-06 · rubric v1.0 · self-assessment

A
TransportPASS

Single Streamable HTTP endpoint; stateless transport; no HTTP+SSE surface.

Stateless corePASS

Fresh server per request, no session map and no per-IP state; module caches hold only shared public data.

Lifecycle and protocol versionPASS

Current MCP SDK handles the handshake; the one declared capability (tools) is fully implemented.

AuthorizationPASS

Authless over read-only public catalog data, which the rubric permits with proportionate abuse controls; every tool serves cached or static data, so there is no expensive surface to abuse.

Tool designPASS

Complete schemas with descriptions, honest annotations (all tools read-only, none open-world), structured errors, bounded outputs.

Security hygienePASS

No subprocess execution, no filesystem writes, no repository cloning, no user file ingestion; zod validation on all arguments; no secrets in the repository.

Notes

  • Verification is local-by-design: verify_plugin returns the recipe to run the open-source verifier on the user’s machine. The server never receives plugin files and never clones repositories (operator policy).
  • No structured abuse logging or alerting yet.
  • History: v1.3.0 briefly shipped server-side clone-based verification behind rate caps; it was replaced the same day by the local-only design, deleting that entire attack surface rather than defending it.

Check yourself before anyone grades you

If you build Claude Code plugins, the same idea already works today: connect the registry's MCP server and ask your Claude to run verify_plugin against your work-in-progress, before you publish. It hands Claude the recipe to run the exact seven checks that gate the Verified by ClaudeRegistry badge, locally, so your code never leaves your machine.

claude mcp add --transport http clauderegistry https://clauderegistry.com/mcp

Request a grade

Run a public MCP server? Get graded, or re-graded at a newer commit. Open an issue with your repository and the commit to grade; drafts go to you before anything is published.

Request a scorecard