The Model Context Protocol's 2026-07-28 revision went final on July 28. It's a meaningful one: the lifecycle moves to stateless requests. If you maintain an MCP server, the two questions are: is my server still well-built, and is it ready for the new spec?
mcpscore answers both in one command:
uvx mcpscore https://your-server.example/mcp
No install, no API key. In a few seconds you get a 0–100 quality score and a list of exactly what to fix.
What it checks
72 deterministic rules, each citing the spec section it enforces, grouped into four categories:
- Protocol: version negotiation, transport correctness, error shapes.
- Tools Quality: names, titles, descriptions, input/output schemas.
- Security & Auth: TLS, auth posture, safe error handling.
- Readiness: how ready you are for the 2026-07-28 lifecycle.
It's deterministic - the same server always gets the same score, so it's stable in CI, and it's read-only: it lists your tools and probes behavior but never calls a tool, so auditing is side-effect-free. Local servers in any language audit over stdio too — mcpscore --stdio ./my-go-server, --stdio java -jar server.jar — not just .py/.js files.
Servers behind OAuth
Most production MCP servers are auth-gated, and until now that meant unauditable. This release changes that:
# full audit with your token (also reads MCPSCORE_TOKEN)
uvx mcpscore --token $TOKEN https://api.example.com/mcp
And with no credentials at all, a 401 server gets a partial audit of its observable surface, including auth-posture rules that check the WWW-Authenticate challenge, RFC 9728 protected-resource metadata, the authorization server's RFC 8414 metadata, and PKCE support. The gate itself Tokens never appear in logs or reports.
In CI
- uses: mcp-box/mcpscore-action@v1
with:
target: https://your-server.example/mcp
min-score: 90
It comments the report on the PR and fails the check below your threshold.
The badge
Add a live score badge to your README from the report page at mcpscore.dev - it reflects your server's latest score.
Why "score", not "audit"
There's a good official conformance suite for "is my server legal." mcpscore is the other question - "how good is it" - the way Lighthouse scores a web page's quality, not just its validity. It runs on the official MCP Python SDK v2, it's open source (MIT), and the methodology is public: https://docs.mcpscore.dev/methodology
Point it at your server and see where you land!
Top comments (5)
A one-command spec check is useful because MCP servers are becoming infrastructure, not demos. The important part is making the output actionable: which capability failed, whether it is a spec mismatch or implementation bug, and what changed from the previous revision.
Thank you, Alex. Curious to hear any feedback from you - can improve anything to make sure it brings value to developers.
The main value for me would be actionable failure output. If the checker can say not only "this server is out of spec," but which contract changed, why it matters, and what a minimal fix looks like, it becomes much more than a compliance command.
Hi Alex, great, this is exactly what the tool provides. Please check mcpscore.dev and let me know if the result is useful - it gives the detailed breakdown of all the validations.
I will take a look. The thing I would test first is whether the result teaches a maintainer what to fix next, not only which validation failed. The best checker output feels like a small repair plan, not just a red mark.