Scoring methodology

Every point in an mcpscore report traces back to one rule, and every rule cites its source in details.basis: a section of the MCP specification for most rules, RFC 9728 for authorization, the MCP Registry server.json schema and the package registries for packaging, JSON-RPC 2.0 for malformed requests, and a named mcpscore recommendation where the spec leaves a field optional. This page follows one real audit from the command to the final number. Then it covers what runs against your server and what the score leaves out, so you can check any score yourself.

# Audit a public server and read the score
mcpscore https://mcp.deepwiki.com/mcp

✅ Server uses HTTPS with valid TLS (TLSv1.3).
✅ No sensitive-data patterns were detected in the sampled error response.
❌ Streamable HTTP does not reject an invalid foreign Origin with HTTP 403, risking DNS rebinding. Observed HTTP status: 200.
  Fix: Validate supplied Origin headers against the origins allowed for this endpoint. Return HTTP 403 for invalid origins; do not allow every origin to satisfy browser requests.
...
Audit finished. Final score: 87/103
Spec: 2025-11-25 negotiated (latest: 2026-07-28) · era: legacy
Readiness for MCP 2026-07-28: 3/13 (informative — not part of the main score; 4 of 20 checks assessed)

That run gives you three numbers: the main score (87/103), the spec revision the server speaks (2025-11-25, legacy), and a separate readiness score for the newest revision (3/13). The rest of this page explains each one.

How 87/103 adds up

A rule is one check against your server, such as security_origin_validation. Each rule has a severity, and the severity sets its weight. A passing rule earns its weight. A failing rule earns nothing. The score is points earned over points available.

Severity	Weight	Typical rules
CRITICAL	5	Protocol version allowed, server name present, TLS enabled
HIGH	3	Server version present, valid tool schemas, `Origin` validated
MEDIUM	2	Titles, tool annotations, error hygiene
LOW	1	Icons, `websiteUrl`, invalid-cursor handling

The same DeepWiki audit, grouped by category:

Category	Earned	Available	Failed rules
Protocol	36	42	`protocol_version_latest` (2), `server_title_present` (2), `server_websiteurl_present` (1), `server_icons_present` (1)
Primitives	35	42	`tools_annotations_present` (2), `tools_title_present_in_all` (1), four `pagination_*_invalid_cursor` rules (1 each)
Security & Auth	16	19	`security_origin_validation` (3)
Total	87	103	11 failed, 28 passed, 43 skipped

Fixing the one Security & Auth failure moves the score to 90/103. The --json report carries the same arithmetic per rule in results[].severity_value and results[].passed, so you can recompute any score from the report alone.

Skipped rules count for nothing

Only rules that ran count toward the maximum. A rule that has nothing to judge is skipped and left out of both numbers, never failed. That is why DeepWiki is scored out of 103 and a server with prompts and resources is scored out of more. DeepWiki serves no prompts or resources, so the 24 rules about them were skipped. Every skip appears in the report’s skipped_rules[] with one reason:

Skip reason	When
`not-applicable`	The rule has no subject: the requirement does not exist for the negotiated revision or transport, or an optional catalog has no items
`insufficient-data`	The observation the rule needs is unavailable, for example a probe errored. The rule can neither pass nor fail
`requires-modern-support`	A readiness detail check on a server with no modern-lifecycle support. The two gateway readiness rules already carry that verdict
`disabled-by-config`	Your project configuration turned the rule off

Technical details: empty and unreadable catalogs

An empty tools catalog that was fetched successfully gives the per-tool rules nothing to assess, so they skip as not-applicable. A declared catalog that could not be fetched skips as insufficient-data instead, because an item may exist unobserved. A separate presence rule, tools_at_least_one, still judges whether a complete tools catalog is empty.

Four categories, readiness counted when it applies

The main score always includes three categories. Readiness is the fourth: it has its own score, and it also counts in the main score on a full audit of a modern or dual-era server. Legacy servers and partial audits leave it out. The server audit has 102 rules today. The rules reference lists each one with its weight and the spec revisions it applies to.

Category	Rules	What it covers
Protocol	17	Protocol version, server name, title and version, advertised capabilities, transport
Primitives	50	Tools, prompts, resources, and resource templates: names, titles, descriptions, JSON Schema validity, URIs, MIME types, annotations, pagination
Security & Auth	15	The server’s security posture, detailed below
Readiness	20	How ready the server is for the 2026-07-28 revision, scored on its own axis and in the main score for modern and dual-era full audits

A separate set of six packaging rules scores a published npm or PyPI package instead of a running server. See package audits.

Security & Auth: the server’s security posture

Security & Auth scores the security posture that is observable on a deployed server, from outside, without calling a tool. OWASP MCP Top 10 coverage maps these rules to the OWASP risks and lists the risks an audit from outside cannot see. The OWASP MCP Top 10 blog post walks through the three catalog-text rules with a working demo.

What is checked	Rules
Transport security: HTTPS with a verified certificate and TLS 1.2 or 1.3 (Authorization §Communication Security)	`security_tls_enabled` (CRITICAL)
`Origin` validation: a request with a foreign `Origin` gets HTTP 403, which blocks DNS rebinding (Transports §Security Warning, Streamable HTTP §Security & Endpoint)	`security_origin_validation` (HIGH)
Error hygiene: a malformed request gets the JSON-RPC parse error, and the error body carries no stack traces, file paths, or credentials (Tools §Security Considerations)	`security_malformed_request_handling`, `security_error_data_leak` (MEDIUM)
Catalog text: every name, title, description, schema string and URI the server lists carries no hidden Unicode (tag characters, bidirectional overrides, control characters, invisible runs), no provider-format credential, and none of a fixed list of prompt-injection phrasings (OWASP MCP Top 10 MCP01, MCP03, MCP06; §Security and Trust & Safety)	`catalog_hidden_unicode`, `catalog_no_embedded_secrets`, `catalog_prompt_injection_phrasing` (HIGH)
Authorization posture, on servers that answer an unauthenticated request with 401 or 403: the `WWW-Authenticate` challenge, RFC 9728 resource metadata, the RFC 8414 authorization-server chain, HTTPS throughout, advertised scopes, and advertised PKCE `S256` support (Authorization, §Authorization Code Protection)	eight `auth_*` rules

Three related checks live in other categories, because the spec files them there. Tool behavior annotations are tools_annotations_present and sensitive tool header parameters are tools_mcp_headers_not_sensitive, both in Primitives. Session-ID handling on the stateless lifecycle is readiness_2026_no_session_id, in Readiness. A server that serves anonymous requests has no authorization posture to grade, so the eight auth_* rules skip as not-applicable. That is the case for DeepWiki above. To score the authorization flow behind the gate, see authenticated servers.

How an audit runs

Connect

Stdio for local servers, Streamable HTTP or SSE for URLs, detected automatically. mcpscore tries the legacy initialize handshake first. If that lifecycle is absent, stateless probes establish whether the target is a modern-only server rather than an unreachable one.

Collect

Protocol version, server info, capabilities, and the complete paginated listings of tools, prompts, resources, and resource templates, plus TLS details for HTTPS targets.

Probe

Sessionless requests that observe behavior the spec defines outside the negotiated session. Probes read state and change nothing. An audit never invokes tools/call. The one opt-in exception is the CLI’s smoke mode, for your own server, reported outside the score.

Evaluate

Every registered rule runs against the collected data and the probe observations.

What the probes send

Several probes are malformed on purpose, because the spec says how a server must answer them. They can look like scanning in a WAF log. Each one checks documented behavior:

Probe	What the spec requires
A foreign `Origin` header	HTTP 403 (Transports §Security Warning)
An unknown RPC method	HTTP 404 with JSON-RPC `-32601` (Streamable HTTP §Protocol Version Header)
An unsupported protocol version	Rejection naming the supported versions (Lifecycle §Protocol Version Negotiation)
A bogus session ID	HTTP 404, not a fresh session (Transports §Session Management)
A request for a nonexistent resource	`-32602` in 2026-07-28, replacing the legacy `-32002` (Resources §Error Handling)
A fabricated pagination cursor on each declared list	JSON-RPC `-32602`, a SHOULD (Pagination §Error Handling)
One truncated JSON body	JSON-RPC `-32700` with a null ID (JSON-RPC 2.0 §Response Object)

Technical details: stdio probes, cursors, and pagination bounds

Stdio gets the same JSON-RPC probes. The modern lifecycle is stateless, so behaviors expressible through the SDK are probed over stdio too, using two short-lived sibling processes and no initialize handshake. The truncated-JSON probe runs only over HTTP, because the SDK path cannot inject malformed wire input safely, so stdio reports insufficient-data for that rule. HTTP-only questions such as Origin, headers, status codes, sessions, and auth metadata are not-applicable for stdio.
Invalid-cursor probes use the initialized session when one exists. Legacy and dual-era servers can reject a sessionless request before the cursor is judged. Modern-only servers are assessed through the stateless path.
Pagination traversal is bounded. For modern servers, mcpscore follows declared paginated lists to compare cacheScope across pages. It is read-only, capped at 100 pages per list and 30 seconds in total, and skips when no list returns more than one complete page.

Scoring across spec revisions

MCP publishes dated revisions, from 2024-11-05 to 2026-07-28. The 2026-07-28 revision replaces the stateful initialize lifecycle with a stateless one. The spec calls stateful servers legacy, stateless servers modern, and servers that speak both dual-era. mcpscore detects which one your server is and scores it against the revision it negotiated:

Rules declare the revisions they apply to. Outside that range they skip as not-applicable, so a server is never failed on a revision it does not speak. DeepWiki negotiates 2025-11-25, so the five tools_mcp_headers_* rules for 2026-07-28 skipped.
The report’s spec.era states which lifecycle was observed, following the spec’s own detection guidance. spec.negotiated_version and spec.latest_version give the revisions.
Modern-only servers are fully supported over HTTP and stdio. When the legacy handshake fails but stateless requests succeed, the audit runs through the probe layer instead of reporting a connection failure.

The readiness score: separate, informative

Readiness answers a second question: how ready is this server for the 2026-07-28 revision. It is always reported on its own axis, as readiness.score over readiness.max_score. Whether its points also count in the main score depends on the server:

Server	Readiness points	Report flag
Legacy only	Informative. A fully compliant 2025-11-25 server keeps a clean main score	`readiness.counted_in_main: false`
Modern or dual-era	Counted in the main score too. The readiness block is the breakdown of that share	`readiness.counted_in_main: true`
Partial audit	Never counted, because a partial score is already not comparable	`readiness.counted_in_main: false`

DeepWiki is legacy, so its 3/13 is guidance only. Its CLI line says 4 of 20 checks assessed: the server has no stateless lifecycle, so the two gateway rules (readiness_2026_server_discover and readiness_2026_stateless_request) failed and 16 detail checks skipped as requires-modern-support. The report carries readiness.assessed, readiness.skipped, and readiness.total, so a perfect fraction never hides checks that did not run.

Technical details: every readiness rule and its normative basis

Each readiness rule is anchored to normative language of the 2026-07-28 revision. The citations are re-checked against the dated spec URLs whenever a revision goes final.

Rule	Severity	Normative basis
`readiness_2026_server_discover`	CRITICAL	Servers MUST implement `server/discover` (Lifecycle §Protocol Version Negotiation; SEP-2575)
`readiness_2026_stateless_request`	CRITICAL	Requests carry their context in `_meta`; the `initialize` handshake is removed (Base Protocol §Statelessness; SEP-2575)
`readiness_2026_supported_versions`	HIGH	`server/discover` MUST list at least one supported version (Lifecycle §Protocol Version Negotiation; SEP-2575)
`readiness_2026_unknown_method_error`	HIGH	Unimplemented methods MUST return HTTP 404 with `-32601` (Streamable HTTP §Protocol Version Header)
`readiness_2026_response_content_type`	HIGH	Successful responses MUST be `application/json` or `text/event-stream` (Streamable HTTP §Sending Messages)
`readiness_2026_meta_validation`	HIGH	Requests missing required `_meta` fields MUST be rejected with `-32602` + HTTP 400 (Base Protocol §_meta)
`readiness_2026_header_validation`	HIGH	Header/body mismatches MUST be rejected with `-32020` (HeaderMismatch) + HTTP 400 (Streamable HTTP §Server Validation; SEP-2243)
`readiness_2026_cache_metadata`	HIGH	List/discover results MUST carry `ttlMs >= 0` and `cacheScope` (Caching §Cacheable Model; SEP-2549)
`readiness_2026_no_session_id`	HIGH	No `Mcp-Session-Id` minted or echoed on modern requests (Streamable HTTP §Earlier Streamable HTTP Revisions; SEP-2567)
`readiness_2026_unsupported_version_error`	MEDIUM	Unknown protocol versions MUST be rejected with `-32022` naming the supported versions (Lifecycle §Protocol Version Negotiation)
`readiness_2026_error_code_migration`	MEDIUM	Missing resources yield `-32602`; the legacy `-32002` MUST NOT be emitted (Base Protocol §Error Codes; SEP-2164)
`readiness_2026_result_type`	MEDIUM	All results carry the `resultType` discriminator (Base Protocol §Result Responses; SEP-2322)
`readiness_2026_deprecated_features`	MEDIUM	Features deprecated in 2026-07-28 (logging; SHOULD NOT adopt) (Deprecated Features; SEP-2577)
`readiness_2026_removed_methods`	MEDIUM	Removed methods such as `ping` rejected with 404 + `-32601`, not served (Changelog §Major Changes; SEP-2575)
`readiness_2026_no_get_stream`	MEDIUM	Modern-only endpoints SHOULD reject the removed standalone GET stream with HTTP 405 (Streamable HTTP §Earlier Streamable HTTP Revisions)
`readiness_2026_missing_protocol_version_rejected`	LOW	Modern-only endpoints MUST reject a missing `MCP-Protocol-Version` with `-32020` + HTTP 400 (Streamable HTTP §Server Validation)
`readiness_2026_missing_method_header_rejected`	LOW	A missing `Mcp-Method` MUST be rejected with `-32020` + HTTP 400 (Streamable HTTP §Server Validation)
`readiness_2026_resource_name_header_mismatch_rejected`	LOW	A `resources/read` `Mcp-Name` that contradicts `params.uri` MUST be rejected with `-32020` + HTTP 400 (Streamable HTTP §Server Validation)
`readiness_2026_prompt_name_header_mismatch_rejected`	LOW	A `prompts/get` `Mcp-Name` that contradicts `params.name` MUST be rejected with `-32020` + HTTP 400 (Streamable HTTP §Server Validation)
`readiness_2026_tool_schema_dialect`	LOW	Tool schemas valid under the default JSON Schema 2020-12 dialect; no network-URI `$ref` (Base Protocol §Schema Dialect, [§ $ref Resolution](https://modelcontextprotocol.io/specification/2026-07-28/basic#$ ref-resolution); SEP-2106)

Origin validation is not on this axis. Every Streamable HTTP revision requires it, so security_origin_validation scores it in Security & Auth for legacy and modern servers alike. The session-ID and removed-method rules check for legacy behavior leaking into the modern lifecycle, so they run only when the server shows modern support. Missing-protocol-version rejection and GET-stream removal skip dual-era endpoints, because the spec permits compatibility with older Streamable HTTP revisions there.

What mcpscore does not test

These are out of scope today, either because they are not observable from outside or because they cannot yet be tested safely from outside:

What tools do. The audit never calls them, so the score judges how tools are described and typed, not how they behave. Smoke mode covers that for your own server, outside the score.
Whether tool descriptions are honest. Catalog text is scanned for hidden characters, credentials and a fixed list of prompt-injection phrasings, not judged for meaning, so a description that misleads in plain words passes.
The package behind the server. mcpscore does not scan code or dependencies for malware. Pair it with a package scanner for that.
True statelessness, meaning no hidden state across requests. Requests from outside can sample it but never prove it.
requestState integrity enforcement. Only tamper rejection is observable, and active tampering probes are deferred.
subscriptions/listen behavior and SSE stream semantics.
The Tasks and MCP Apps extensions, which version separately from the core spec.
Client-side OAuth obligations such as issuer validation and credential binding. A server audit cannot observe them.

When the score changes

The score is deterministic: the same server state and the same mcpscore version give the same score. When it moves, one of three things moved:

A different mcpscore version ran. Most releases add rules, which changes both numbers. The report’s mcpscore_version names the engine. Scores compare only within one version, per the stability contract.
The audit type differs. A partial audit covers far fewer checks. A modern server’s main score includes readiness points (readiness.counted_in_main) and a legacy server’s does not.
The server answered differently. Rolling deploys and mixed replica versions behind a load balancer give identical probes different answers. A server that rate-limits the probes turns rules into insufficient-data skips, which changes the maximum.

To find the cause, diff the two --json reports by rule_id. The rule that flipped is the finding. For fixes to the rules servers fail most, see improve your score.

Disputing a rule

Open an issue with the rule_id and the spec text you believe contradicts it. Every rule must be defensible by citation, and a rule that is not is a bug. Most results carry their citation in details.basis, and readiness results in details.sep. To propose a new rule, see CONTRIBUTING.

Get started

Guides

Use in CI

Scoring

Reference

Scoring methodology

How 87/103 adds up

Skipped rules count for nothing

Four categories, readiness counted when it applies

Security & Auth: the server’s security posture

How an audit runs

What the probes send

Scoring across spec revisions

The readiness score: separate, informative

What mcpscore does not test

When the score changes

Disputing a rule

What’s next

Rules reference

Stability contract

​How 87/103 adds up

​Skipped rules count for nothing

​Four categories, readiness counted when it applies

​Security & Auth: the server’s security posture

​How an audit runs

​What the probes send

​Scoring across spec revisions

​The readiness score: separate, informative

​What mcpscore does not test

​When the score changes

​Disputing a rule

​What’s next

Rules reference

Stability contract

How 87/103 adds up

Skipped rules count for nothing

Four categories, readiness counted when it applies

Security & Auth: the server’s security posture

How an audit runs

What the probes send

Scoring across spec revisions

The readiness score: separate, informative

What mcpscore does not test

When the score changes

Disputing a rule

What’s next