createmcps.com

Validate an MCP server

Paste a live server URL and we'll check it against all 79 rules of the 2026-07-28 specification — statelessness, required headers, caching metadata, authorization, and more. See the full rule catalog.

First time? Read the walkthrough — what we send to your server, how the grade is worked out, and why most results come back unrated.

Runs through SSRF admission control before anything is fetched. Every probe is read-only: no tool is called, no resource is read, and requests needing a tools/call shape use a reserved sentinel name.

Example reportmcp.example.com
D

1 fail · 1 warn · 91% coverage

spec 2026-07-28 · ruleset 1.4.2

  • MCP-STL-001pass
  • MCP-HDR-003fail
  • MCP-CAC-002pass
  • MCP-AUT-005warn
  • MCP-SEC-001pass

pass = satisfied · warn = SHOULD violated · fail = MUST violated

Two ways to validate

Live · works today

Remote server URL

We make live, read-only protocol requests against your running server — the form above. Admission control runs first, then ten probe groups covering the full rule catalogue, inside a 25-request, 30-second budget.

Live · works today

Paste a server.json

Static analysis for a server that isn't deployed anywhere yet — required fields, namespace form, semver, and the registry rules that reject a publish. Nothing is fetched or stored. Source-code analysis is a separate problem and isn't part of this.

Not deployed yet? Check your server.json

The registry rejects a publish for reasons that are hard to read from the error alone — a namespace that isn't reverse-DNS, a missing packages or remotes, a private registry URL. This checks those before you run mcp-publisher.

Nothing is fetched, stored, or published — this runs entirely on the pasted text.

What gets checked

79 rules across six categories. 75 of them link to the exact sentence of the spec they come from; the rest are security and registry best practices.

  • Discovery & capabilities
  • Required headers
  • Statelessness
  • Caching metadata
  • Authorization
  • Deprecated & registry

How grading works

A simple, published, versioned rubric. Any security-relevant fail caps the grade at D.

  • A0 fails, 0 warns, coverage ≥ 80%
  • B0 fails, ≤ 3 warns
  • C0 fails, > 3 warns
  • D1–2 fails
  • F≥ 3 fails

Is my report public?

Yes — every report is public by default. It gets a permanent URL showing the server's hostname, its grade, and every finding, so it can be linked and cited. There is no ownership check today, which means anyone can validate any server: please only validate servers you own or have permission to test. If a report about your server shouldn't be public, tell us and we'll take it down — see the security & disclosure page.

Frequently asked

Is it safe to run this against a production server?

Yes — every probe is read-only. We never call a real tool, read a real resource, or invoke a real prompt; checks that need a tools/call-shaped request use a reserved sentinel name instead. The target URL also passes through an SSRF-safe admission check before anything is fetched.

Will my report be public?

Yes. Reports are public by default and get a permanent, shareable URL showing the target's hostname, its grade, and every finding. That is deliberate — public reports are what make the compliance corpus useful — but it means anyone can validate any server, so please only validate servers you own or have permission to test. If a report about your server should not be public, contact us and we will remove it.

How long does a validation take?

The design budget is a handful of HTTP requests completing in under 30 seconds — deliberately small and fast, not a slow crawl of your server.

What's the difference between a warn and a fail?

fail means a MUST requirement in the spec is violated; warn means a SHOULD requirement is violated. Separately, if a fail was only detected heuristically rather than with full certainty, we bump the overall letter grade up one level to compensate — we don't want an inference-based check alone to tank a compliant server's grade.