How we rank public MCP servers from the outside.
A published Score for production MCP URLs: did we reach the server, negotiate the protocol, list tools, complete a call, and get a result that looks like the job. See the live scores. Named-host comparison is on MCP validation, not this leaderboard.
What the Score measures
The path after the URL, not the URL alone.
The Public MCP Score measures a production MCP endpoint the way a client must: reach it, negotiate the dialect, discover the catalog, invoke a safe tool, and record whether the result looked like work got done.
Listed is not called. Called is not the job. A 200 on the address is one input, not the Score. This is not a popularity list and not a lab capability benchmark.
Honest limit: the public Index is one outside-in client path per server. It does not rank Cursor against Claude against VS Code. That record is the product monitor.
Reach the MCP URL
Confirm the endpoint answers. Reach is the first artifact, not the product.
Negotiate the dialect
Modern 2026-07-28 path first (server/discover + per-request meta). Legacy initialize/session if required.
Read the catalog
tools/list, plus resources and prompts when the server exposes them.
Call a tool and score the job
Safe read tools (and schema-linked paths when the catalog supports them). Invocation and functional outcome are scored separately.
Roll 30 days into the Score
Per-run evidence becomes Reach, P95, Invoke, Functional, Spec, protocol-era badges, and Rank Score.
What a URL check misses
Green address, dead path.
Most MCP “uptime” is a ping on the URL. Hosts fail later: the catalog is empty, the call errors inside a 200, the job never lands, or only one protocol era works. Those are the failures the Score is built to surface.
Listed is not called
Called is not the job
Protocol-era split
Half a session
Thin sample luck
How probes run: distributed nodes execute the workload. The backend only schedules and scores. Residential origin is the execution path, not the claim of the Score.
Protocol eras
Modern, legacy, dual, and Spec readiness.
MCP clients are mid-migration. A server that only answers legacy initialize + Mcp-Session-Id will fail modern clients. A server that only answers the stateless 2026-07-28 path will fail older SDKs. We negotiate both and publish which dialect worked.
Modern (2026-07-28)
Legacy (session)
Dual-era
Broken / split
Spec readiness is a separate 0-100 migration score from the dual-era probe (modern path, server/discover, header routing, list-cache hints). Filter the Index by protocol era.
Paid monitors can probe both eras every cycle (Growth+) to catch asymmetric deploys. The public Index always negotiates modern-first with legacy fallback so every listed server is measured on a comparable path.
Signals
What each column answers.
Each public column answers one question, and has an explicit non-claim:
Reach (30d)
What share of MCP validation runs reached the server?
Latency P95
How slow were the slowest successful probes?
Invoke
Did tools/call complete with a well-formed MCP result?
Functional
Did the result look like the tool did its job?
Spec
After dual-era negotiate, did transport, discovery, and invocation look like MCP?
Runs
How many scored validation runs sit in the 30-day window?
Score
Score calculation.
The Score is a composite from 0 to 100:
reachable_runs / total_mcp_runs over the last 30 days. Run-based reachability, not a continuous synthetic heartbeat.
P95 response time mapped to 0-100. Perfect score at ≤200 ms. Linear decay to 0 at ≥2000 ms.
invocation_rate × 0.6 + functional_rate × 0.4. Falls back to whichever rate exists if only one is present.
Average per-run score after dual-era negotiate: reachable 30% + transport 25% + discovery 25% + invocation 20%. Missing invocation evidence renormalizes the rest.
Verdict bonus (ranking math)
Operational
Impaired
Down
If a component is missing, remaining weights renormalize. The verdict bonus is still applied. Final score is capped at 100. Spec readiness sits beside the Score and is not folded into these weights.
Displayed vs Rank
Why the drawer and the table can disagree.
The Index shows two scores for the same server. Thin evidence is not allowed to dominate the leaderboard.
Displayed Score
Rank Score
Confidence shrinkage (rate components only)
For reach, tool success, and protocol conformance (each as a 0-1 rate p with n runs), Rank Score first replaces p with a blend toward a neutral prior. Latency P95 is not shrunk. The measured curve stays.
n₀ = 7 · prior p₀ = 0.5 (50%) · Low sample when n < 7
Then Rank Score = weighted(p_rank rates, unchanged latency score) + same verdict bonus. As n grows, p_rank → p and the two scores converge.
Worked example (n = 2 runs)
Suppose Reach, Tool, and Spec are all 100%, P95 latency is 1575 ms (latency score ≈ 23.6), and status is Operational (+5).
| Step | Math | Result |
|---|---|---|
| Displayed base | 0.35×100 + 0.25×23.6 + 0.25×100 + 0.15×100 | 80.9 |
| Shrink each 100% rate | (2/9)×1.0 + (7/9)×0.5 | 61.1% |
| Rank base | 0.35×61.1 + 0.25×23.6 + 0.25×61.1 + 0.15×61.1 | 51.7 |
| Rank Score | 51.7 + 5 (Operational) | 56.7 |
The drawer can show about 80.9 while the table sorts on 56.7. That gap is the point.
Ranking rules
Eligibility, ranking, and sample size.
Indexed
Hidden
Ranked
Displayed Score
Rank Score
Low sample
Unrated
Identity
Status chip
Protocol era filter
Freshness
Cadence and data freshness.
| Surface | Freshness |
|---|---|
| Validation runs | Per monitor schedule (public MCP fleet commonly about 6h; configurable down to 5 min) |
| Live leaderboard | Computed from the latest 30-day window of MCP validation results |
| Trend delta | Vs yesterday’s daily Score snapshot (00:15 UTC). Null until day 2 of snapshots |
| Validation runs counter | Real 30-day run count for indexed servers |
The split
What we are, and are not.
We are not
- • A paid placement directory
- • A full MCP spec certification body
- • A named-host matrix for every public row
- • An inside-out APM or tracing product
We are
- • An independent outside-in validator of public MCP URLs
- • A public reliability ranking with published math
- • A dual-era client: modern MCP first, legacy when required
- • Honest about listed vs called vs the job
FAQ
Common questions.
| Question | Answer |
|---|---|
| Is this a lab benchmark of MCP servers? | No. We probe production MCP URLs on a schedule and score whether the path held: reach, negotiate, list tools, call a safe tool, and whether the result looked like the job. It is reliability in the wild, not a capability bake-off in a lab. |
| Do you rank Cursor vs Claude vs VS Code on this page? | No. The public Index is one outside-in client path per server. Named-host comparison lives on the product monitor. See MCP validation. This page documents the public Score only. |
| What goes into the Score? | Four weighted signals plus a small verdict bonus: reach (35%), latency (25%), tool success (25%), and protocol conformance (15%). Missing components renormalize the remaining weights. The formula is public. |
| What is dual-era negotiation? | MCP clients are mid-migration. We try the modern 2026-07-28 path first (stateless server/discover + per-request meta, no sticky Mcp-Session-Id), then fall back to legacy initialize/session when required. Spec readiness and protocol-era badges report which dialect actually worked. |
| What is Spec readiness? | A 0-100 migration score from the dual-era probe: modern path, server/discover, header routing, and list-cache hints. Separate from the composite Score. It answers how ready this server is for modern MCP clients. |
| Why does status say “Modern only, legacy fails” instead of Degraded? | When we know the cause, the public Status chip names it: modern-only, legacy-only, multi-edge protocol split, auth required, unreachable, and similar. Internal severity can still be degraded for ranking math. The label is never opaque when the probe classified the failure. |
| How is reach measured? | Run-based reachability over the last 30 days: reachable MCP validation runs divided by total MCP validation runs for that server. This matches the monitor schedule (public MCP monitors are commonly about every 6 hours; paid agents can schedule down to 5 minutes), not a fake continuous heartbeat. |
| What does tool success mean? | A blend of invocation (did tools/call complete with a well-formed MCP result?) at 60% and functional (did the result look correct for the tool's purpose?) at 40%. If only one signal exists, we use that one. The default public path exercises safe read tools with synthesized arguments, not a full contract suite unless a monitor is configured for deeper jobs. |
| What is protocol conformance? | Per-run adherence to the MCP surface we exercise after dual-era negotiation: reachability, transport support, tool discovery, and invocation. Those pieces are weighted 30% / 25% / 25% / 20% and averaged across runs. It is not a full optional-feature certification of every MCP extension. |
| Why does the drawer show one Score and the table another? | Two intentional numbers. Displayed Score (drawer) is the raw composite from measured rates. The table Score, and sort order, use Rank Score: the same formula after confidence shrinkage on rate components (reach, tool success, protocol conformance) toward a 50% prior with strength 7. Latency is never shrunk. Under 7 runs the gap is large on purpose. At high sample the two converge. |
| Why are some servers marked Low sample? | Fewer than 7 validation runs in the scoring window. They still get a Displayed Score. Leaderboard position uses Rank Score so a lucky 2-run streak cannot outrank a proven fleet. Worked math is in Displayed vs Rank. Unrated means zero scored runs. |
| Can a server pay for a better rank? | No. Rankings come from measured results only. Paused monitors are hidden from the public index entirely. |
| Do you publish internal IDs? | No. The public index uses display names and stable slugs only. |
Independence
Trust is measured, not purchased.
The Public MCP Score is operated by Carmel Labs / AgentStatus as an independent validator. Rankings are determined by measured validation results. Server operators cannot pay for a better score.
The only way to move up is to improve reach, latency, invocation, functional result, protocol conformance, and dual-era readiness under the same outside-in path.
