A second opinion: mcpsnoop

mcpsnoop is the one other tool that judges a recorded MCP session offline: mcpsnoop check reads a capture and fails on a fixed set of rules. The official suite calibrates this project against live scenarios; mcpsnoop calibrates it against a reader of recordings, which is what this project is. This page is that comparison over all 358 corpus traces, with every disagreement triaged: which tool is right, by which clause, and what was done about it.

How the comparison is made

The binary. mcpsnoop 0.26.1, the current npm release when measured, taken from the npm registry and never built from source. The mcpsnoop package is a launcher with no install script; the Go binary ships in a per-platform package. Both tarballs were fetched with npm pack and checked against the registry’s integrity:

• [email protected] — sha512-midlHuFR9PGrrW8BUm/F16k76ccPmVfE8OVBWR7DkSQzZjaGookgTH4ACpytuWnD5VnKIxvNN2Y8smwjyq4xMw==
• @mcpsnoop/[email protected] — sha512-mNsXyDgs4vznFP6BQz9oxAJYLEo+I2YC2F9vDICd5Z4FSUPTjHWT/A6HW+i6/FvyUu0Ymf3HnMc2zM9X2xZQ2Q==

The binary inside, package/bin/mcpsnoop, has SHA-256 81c3636fa5a371833ab4558d6ac417d9d94a86f99949e0cff32bb09ccf69c2a9. To measure, point MCPSNOOP at it and run cargo xtask mcpsnoop; without it the task skips loudly. mcpsnoop is never a gate on a pull request — a scheduled, informational job re-measures it.

The same session in front of both. Our traces are converted into the capture format mcpsnoop writes itself (xtask/src/mcpsnoop/convert.rs). On stdio the conversion is lossless. On HTTP a frame gets the headers, status and exchange the trace’s own order settles — the rules our validator’s framing applies — and no more; a frame whose context the trace cannot settle is marked unframed, and a finding that reads such context there is set aside, not counted. The conversion is checked against mcpsnoop’s own recordings on every measurement: sessions recorded through both tools at once — the reference host against the everything server, committed under conformance/mcpsnoop/native/ — must draw the same mcpsnoop findings from the converted trace as from mcpsnoop’s capture once that capture’s frames share one connection, the single field the conversion fixes rather than carries. In the committed run 3 of 3 such sessions did: http-2025-11-25 (28 findings), http-2026-07-28 (22 findings), stdio-2025-11-25 (28 findings).

What is compared. mcpsnoop’s conformance signals — invalid, warn and mismatch, the three its own rule descriptions call protocol violations — against our fail and warn rows, an extension’s among them although they never decide our verdict, and the wire schema. Its other signals (a call that ended in an error, one still pending when the capture ended, a deprecated feature) are counted per trace but say nothing about conformance. Each mcpsnoop rule is mapped to the registry clauses its condition violates, read from both texts (conformance/mcpsnoop/rules.json, tabulated below); a mapping is partial where the rule checks only part of the clause. Then, per trace: a fired rule one of whose clauses we flag is agreement; a fired rule none of whose clauses we flag is a mcpsnoop-only divergence; a clause we flag that a rule maps fully, with that rule silent, is an ours-only divergence; a clause we flag that no rule maps fully is beyond mcpsnoop, a difference of scope rather than of reading.

Summary

Verdicts, ours against mcpsnoop’s conformance signals:

Traces by how the two readings relate:

mcpsnoop flagging less than we do is mostly scope, not disagreement: its rules cover a part of the registry, and the traces it passes while we fail are the beyond mcpsnoop row. Across the corpus we flag 268 distinct clauses (counted per revision) that no mcpsnoop rule maps fully. Findings were set aside for reading HTTP context the conversion could not supply on 7 traces.

Divergences

Every divergence the run shows, and its triage (conformance/mcpsnoop/triage.json). --check fails while any divergence is untriaged or any triage entry matches nothing.

1. invalid-frame (mcpsnoop-only)

The server answers initialize with "code": -32602.5. We report BASE-007, the clause that names the defect; mcpsnoop’s decoder refuses the frame and reports it as not JSON-RPC at all. Both are true — a non-integer code breaks JSON-RPC 2.0, which BASE-008 incorporates — and the two readings convict the same frame. The difference is only which clause carries the finding: ours attributes it to the most specific clause and leaves BASE-008 to framing faults, mcpsnoop has no rule finer than the parse.

BASE-007 (MUST): Error codes MUST be integers. — source

BASE-008 (MUST): All messages between MCP clients and servers MUST follow the JSON-RPC 2.0 specification. — source

Resolution: none: the same defect on the same frame, reported at different granularity

2. request-id-in-flight (mcpsnoop-only)

On Streamable HTTP the client POSTs tools/call id 1 and the server answers that POST, in its own application/json body, with an error whose id is null although the request’s id was readable — a BASE-052 violation both tools report. The client then sends a new tools/call reusing id 1. mcpsnoop reports the reuse as an id already in flight: having failed to match the null-id error by id, it keeps request 1 open forever. But the answer arrived as the response to that very POST, so the client has received a response for it, and BASE-045 forbids reuse only of an id the sender has “not yet received a response for”. Our framing ties a null-id answer to the request whose exchange framed it; mcpsnoop records the exchange (exchange is in its own capture) but does not use it here. The conversion is not the cause: the request and the error carry the same exchange, exactly as mcpsnoop’s proxy records them.

BASE-045 (MUST NOT): The request ID MUST NOT match the ID of any other request the sender has issued and not yet received a response for. — source

BASE-052 (MUST): Error responses MUST include the same ID as the request they correspond to (except in error cases where the ID could not be read due a malformed request). — source

Resolution: upstream: mcpsnoop-null-id-answer

3. server-rejected-header-mismatch (mcpsnoop-only)

In each trace the server answers -32020 (HeaderMismatch) to a POST whose headers match its body: a tools/list with every header correct (tran-098), and a tools/call that omits Mcp-Param-Region because region is null or absent — exactly what the client must do (tran-133, tran-135). mcpsnoop reports each as “a routing header disagrees with the body”. By its own documentation a server’s -32020 “counts as the same condition” as a disagreement, so it takes the server’s word over its own comparison — which on these frames found nothing. The defect is the server’s (TRAN-133/TRAN-135: the server MUST NOT expect the header; TRAN-098: the rejection must be 400), and mcpsnoop’s finding attributes it to the client’s headers. Where the client really was at fault (tran-089-sentinel-markers-miscased, tran-077-param-header-value-rejected, tran-079-param-header-value-not-mirrored) the same rule agrees with us.

TRAN-133 (MUST NOT): Parameter value is null | Client MUST omit the header | Server MUST NOT expect the header — source

TRAN-135 (MUST NOT): Parameter not in arguments | Client MUST omit the header | Server MUST NOT expect the header — source

TRAN-098 (MUST): Servers MUST reject requests with a 400 Bad Request HTTP status and JSON-RPC error code -32020 (HeaderMismatch) if any validation fails. — source

Resolution: upstream: mcpsnoop-trusts-header-mismatch-rejection

4. BASE-030 (ours-only)

Each trace’s only request carries "_meta": {} — no protocol version anywhere, in the body or (base-032, HTTP) in a header. We judge the trace at 2026-07-28 because the corpus files it under draft/, which is how this repository assigns a revision; mcpsnoop infers the revision from the session and finds none, so it applies no 2026-07-28 rule. Given what each tool is told, each is right: an empty _meta is a violation at 2026-07-28 and none at 2025-11-25. mcpsnoop does flag the same field set as missing wherever the session names 2026-07-28 (base-030-request-meta-missing-required-field and the probe capture agree with us).

BASE-030 (MUST): Client requests carry the following io.modelcontextprotocol/* fields in meta; fields marked as required MUST be included on every request. — source

Resolution: none: the revision is stated to our validator out of band and is absent from the trace

5. MRTR-002 (ours-only)

The same request and the same reasoning as BASE-030 above: MRTR-002 restates the rule on the multi round-trip page.

MRTR-002 (MUST): Every request MUST include the required meta fields; see meta. — source

Resolution: none: the revision is stated to our validator out of band and is absent from the trace

6. TOOL-016 (ours-only)

The same request and the same reasoning as BASE-030 above: TOOL-016 restates the required _meta fields on the tools page.

TOOL-016 (MUST): Every request MUST include the required meta fields; see meta. — source

Resolution: none: the revision is stated to our validator out of band and is absent from the trace

7. BASE-030 (ours-only)

A legacy client sends initialize naming 2025-11-25. In vers-008 the server speaks only 2026-07-28 and refuses; in base-030-legacy-initialize-negotiated-2026-07-28 it answers naming 2026-07-28 and the session goes on under it. Judging the whole trace at 2026-07-28 (the corpus’s draft/ assignment for the first; the server’s initialize result, which is the session’s revision, for the second), we report the initialize as a request missing the required _meta fields — deliberately: checks/stateless/meta.rs exempts this request from BASE-031, citing basic/versioning‘s compatibility matrix (which says of exactly this request that it “also lacks the required _meta fields”), and states that the client’s own defect is still reported, by BASE-030. mcpsnoop 0.26.1 draws nothing on either trace. Measured 2026-10-25 on edited copies of the second trace’s converted capture: it applies request-meta-missing to a request only when that request’s own _meta carries io.modelcontextprotocol/protocolVersion 2026-07-28 (an initialize whose _meta names it and lacks the other fields is flagged, so initialize is not exempt); a request with no _meta, an empty one, or one naming 2025-11-25 draws nothing, and setting the initialize params’ protocolVersion to 2026-07-28 changes nothing. So its per-request revision is the one the request states in _meta, not params.protocolVersion and not the server’s answer; an earlier version of this note said it reads the request’s own protocolVersion, which that measurement does not support. Whether a 2026-07-28 clause binds a request that is itself speaking 2025-11-25 is not settled by the text: the matrix describes the request as lacking the fields without saying the legacy client is non-conformant for it, and nothing makes a 2025-11-25 client subject to 2026-07-28. The same question sits under our TRAN-071 finding on the probe capture’s legacy initialize.

BASE-030 (MUST): Client requests carry the following io.modelcontextprotocol/* fields in meta; fields marked as required MUST be included on every request. — source

VERS-008 (SHOULD): A server that supports only modern versions SHOULD name the protocol versions it supports in any error it returns to an initialize request, on any transport: legacy clients have no fall-forward mechanism, and this message may be the only diagnostic they can surface to users. — source

Resolution: open: decide whether a legacy-era request inside a 2026-07-28 trace is held to that revision’s request-envelope clauses (BASE-030 and its restatements, TRAN-071); the current reading is recorded in checks/stateless/meta.rs

8. MRTR-002 (ours-only)

The legacy initialize of either trace above, under MRTR-002’s restatement of the same rule.

MRTR-002 (MUST): Every request MUST include the required meta fields; see meta. — source

Resolution: open: the same decision as BASE-030 on these traces

9. TOOL-016 (ours-only)

The legacy initialize of either trace above, under TOOL-016’s restatement of the same rule.

TOOL-016 (MUST): Every request MUST include the required meta fields; see meta. — source

Resolution: open: the same decision as BASE-030 on these traces

10. LIFE-018 (ours-only)

A 2025-11-25 HTTP session negotiates, then sends a request without MCP-Protocol-Version. 2025-11-25 requires the header on every request after initialization; mcpsnoop’s rule for a missing routing header (“missing where the negotiated revision requires it”) fires only at 2026-07-28. Reproduced on a session recorded by mcpsnoop’s own proxy, so the conversion is not the cause: native/version-header-omitted-2025-11-25.mcpsnoop.jsonl (initialize, notifications/initialized with the header, tools/list without it) passes mcpsnoop check with every signal enabled.

LIFE-018 (MUST): If using HTTP, the client MUST include the MCP-Protocol-Version: <protocol-version> HTTP header on all subsequent requests to the MCP server. — source

TRAN-017 (MUST): If using HTTP, the client MUST include the MCP-Protocol-Version: <protocol-version> HTTP header on all subsequent requests to the MCP server, allowing the MCP server to respond based on the MCP protocol version. — source

Resolution: upstream: mcpsnoop-version-header-2025-11-25

11. TRAN-017 (ours-only)

The transport page’s statement of LIFE-018’s rule; the same missing header and the same mcpsnoop gap.

TRAN-017 (MUST): If using HTTP, the client MUST include the MCP-Protocol-Version: <protocol-version> HTTP header on all subsequent requests to the MCP server, allowing the MCP server to respond based on the MCP protocol version. — source

Resolution: upstream: mcpsnoop-version-header-2025-11-25

12. response-unmatched (mcpsnoop-only)

A POST carrying Host and Origin evil.example.com is refused with HTTP 403 and a JSON-RPC error that has no id; the session then proceeds from localhost. The transport’s security warning, at both revisions, describes exactly that answer: “If the Origin header is present and invalid, servers MUST respond with HTTP 403 Forbidden. The HTTP response body MAY comprise a JSON-RPC error response that has no id.” The refusal happens before the request is read, so there is no id to echo, and BASE-009/BASE-052’s id rule does not reach a body the transport clause permits to have none. mcpsnoop reports the id-less error as matching no request. We did the same, as BASE-009, until 2026-10-13 — on the official suite’s dns-rebinding-protection scenario against the everything server (conformance/wire-findings.json) — and these two traces are the regression pair for that fix.

BASE-009 (MUST): Error responses MUST include the same ID as the request they correspond to (except in error cases where the ID could not be read due a malformed request). — source

BASE-052 (MUST): Error responses MUST include the same ID as the request they correspond to (except in error cases where the ID could not be read due a malformed request). — source

Resolution: upstream: mcpsnoop-origin-refusal-unmatched

13. progress-after-completion (mcpsnoop-only)

A conforming 2025-11-25 task session: the server answers a task-augmented tools/call with a CreateTaskResult (seq 4) and sends progress under the request’s token while the task is working (seq 5, and seq 10 after a tasks/get that still says working); the task is completed only at seq 12. The tasks page has the token “continue to be used for progress notifications throughout the task’s lifetime, even after the CreateTaskResult has been returned” (PROG-014) and stops progress at the task’s terminal status (PROG-016), which this session respects; our validator passes it. mcpsnoop 0.26.1 warns on both notifications as arriving “after its request completed”, with the text “2026-07-28 requires them to stop”: it takes the CreateTaskResult for the request’s completion and applies that revision’s rule to a 2025-11-25 session. The same rule fires, correctly, on prog-019 (progress after an ordinary response) and, for the earlier of its two notifications, wrongly on prog-016 for the same reason as here; both traces agree with us at the trace level.

PROG-014 (MUST): For task-augmented requests, the progressToken provided in the original request MUST continue to be used for progress notifications throughout the task’s lifetime, even after the CreateTaskResult has been returned. — source

PROG-016 (MUST): Progress notifications for tasks MUST stop after the task reaches a terminal status (completed, failed, or cancelled) — source

Resolution: open: whether to report it upstream is the maintainer’s call; the reproduction is corpus/good/stdio-task-progress.jsonl, whose task handling the 2025-11-25 tasks page defines (PROG-014)

Found on live recordings

Divergences that only a session recorded by mcpsnoop itself shows, because they turn on something our trace format does not record.

response-unmatched — mcpsnoop-defect, right: ours

Recorded live: the reference host drives the everything server over Streamable HTTP at 2025-11-25, through mcp-trace-capture and mcpsnoop’s proxy at once. The server sends elicitation/create (and sampling/createMessage) on a tool call’s SSE stream; the client answers each with a new POST, as the transport requires — and its HTTP pool sends that POST on a different TCP connection. mcpsnoop pairs a server request with its answer only within one connection, so it reports each answer as “response id has no matching request” and each server request as never answered: five false warn findings and five false pending ones. Rewriting the capture’s conn_id to one value removes exactly those ten and nothing else, and our converted trace — which carries no connection — draws the remaining findings exactly. A JSON-RPC id is scoped to the session, never to a connection, and nothing obliges a client to reuse one.

Evidence: conformance/mcpsnoop/native/http-2025-11-25.mcpsnoop.jsonl, conformance/mcpsnoop/native/http-2025-11-25.trace.jsonl.

BASE-003 (MUST NOT): The request ID MUST NOT have been previously used by the requestor within the same session. — source

TRAN-024 (MUST): Every JSON-RPC message sent from the client MUST be a new HTTP POST request to the MCP endpoint. — source

Resolution: upstream: mcpsnoop-connection-scoped-ids

protocol-version-header-missing — mcpsnoop-defect, right: ours

The live reproduction of divergence LIFE-018 above: a 2025-11-25 session through mcpsnoop’s proxy whose tools/list POST omits MCP-Protocol-Version after a completed handshake. mcpsnoop check with every signal enabled exits 0.

Evidence: conformance/mcpsnoop/native/version-header-omitted-2025-11-25.mcpsnoop.jsonl.

LIFE-018 (MUST): If using HTTP, the client MUST include the MCP-Protocol-Version: <protocol-version> HTTP header on all subsequent requests to the MCP server. — source

TRAN-017 (MUST): If using HTTP, the client MUST include the MCP-Protocol-Version: <protocol-version> HTTP header on all subsequent requests to the MCP server, allowing the MCP server to respond based on the MCP protocol version. — source

Resolution: upstream: mcpsnoop-version-header-2025-11-25

Upstream issue drafts

Written for mcpsnoop’s tracker and not filed: filing is the owner’s call.

mcpsnoop-connection-scoped-ids: check: server-to-client requests answered on another connection are reported as unanswered (HTTP)

Version: mcpsnoop 0.26.1 (npm, linux-x64).

What happens. On a streamable-HTTP session at 2025-11-25, the server sends elicitation/create on a tools/call SSE stream. The client answers it with a new POST, as the transport requires (“Every JSON-RPC message sent from the client MUST be a new HTTP POST request to the MCP endpoint”). The client’s HTTP pool sent that POST on a different TCP connection, so it was recorded with a different conn_id. mcpsnoop check then reports response id has no matching request (warn) on the answer and elicitation/create (id 0) never got a response (pending) on the request — once per server request in the session.

Expected. A JSON-RPC id is scoped to the session, not to a connection (2025-11-25 basic: “The request ID MUST NOT have been previously used by the requestor within the same session”), and a client may send each POST on any connection. A server request should be paired with the client’s response by id within the session.

Evidence. Recorded by mcpsnoop http in front of a streamable-HTTP server, with the reference client answering four elicitation/create and one sampling/createMessage: ten findings (five warn, five pending). Rewriting every conn_id in the capture to one value and re-running check removes exactly those ten.

Suggested fix. Key outstanding server-to-client requests by session (and direction), not by conn_id; keep the connection only for routing-header attribution.

mcpsnoop-null-id-answer: check: an id-less error returned in a POST’s own body leaves the request in flight, so a later reuse is reported

Version: mcpsnoop 0.26.1.

What happens. Streamable HTTP, 2026-07-28. The client POSTs tools/call with id: 1; the server answers that POST, in its own application/json body, with {"jsonrpc":"2.0","id":null,"error":{"code":-32602,...}}. check correctly reports response id has no matching request — the id was readable, so the server should have echoed it. The client then POSTs a new request reusing id: 1, and check reports request reuses an id already in flight.

Expected. The request is not in flight: its answer arrived as the response to the very POST that carried it, and both envelopes carry the same exchange. The specification forbids reusing an id only while “the sender has issued and not yet received a response for” it. The null id is the server’s defect, already reported; the reuse is not the client’s.

Suggested fix. On HTTP, when a response with a null (or unmatched) id arrives on an exchange that carried exactly one request, close that request — or at least do not count it as in flight for the reuse rule.

mcpsnoop-trusts-header-mismatch-rejection: check: a server’s -32020 is reported as “a routing header disagrees with the body” even when every header matches

Version: mcpsnoop 0.26.1.

What happens. Streamable HTTP, 2026-07-28. A tools/call whose tool marks region with x-mcp-header, sent with "region": null and therefore no Mcp-Param-Region header — the behaviour table says “Parameter value is null | Client MUST omit the header | Server MUST NOT expect the header”. The server wrongly rejects it with -32020 (HeaderMismatch). check reports mismatch: a routing header disagrees with the body. The same happens when the parameter is absent from the arguments, and when a server answers -32020 to a tools/list whose Mcp-Method and MCP-Protocol-Version match the body.

Expected. No header disagrees with the body in these requests, and mcpsnoop’s own comparison found none. The faulty party is the server. The rule description says a server’s -32020 “counts as the same condition”, which convicts the client’s headers on the server’s word.

Suggested fix. Report a -32020 as a mismatch only when mcpsnoop’s own comparison agrees, or could not be made (for instance, the tool definition was not captured). When the comparison ran and found the headers consistent, report the rejection as the server’s — a separate message, or none.

mcpsnoop-version-header-2025-11-25: check: a missing MCP-Protocol-Version header is not reported on 2025-11-25 sessions

Version: mcpsnoop 0.26.1.

What happens. A streamable-HTTP session negotiates 2025-11-25 (initialize, then notifications/initialized carrying MCP-Protocol-Version: 2025-11-25), then POSTs tools/list without the header. check --fail-on error,invalid,warn,mismatch,pending,late-result,duplicate,deprecated,incomplete exits 0.

Expected. 2025-11-25 requires the header: “If using HTTP, the client MUST include the MCP-Protocol-Version: <protocol-version> HTTP header on all subsequent requests to the MCP server.” The mismatch signal’s description already covers a routing header that “is missing where the negotiated revision requires it”; at present only 2026-07-28 is treated as requiring it.

Reproduce. mcpsnoop http --target <server>/mcp, then with curl: an initialize POST, an initialized POST with the header and the returned Mcp-Session-Id, and a tools/list POST with the session id but no MCP-Protocol-Version. Run mcpsnoop check on the session.

Suggested fix. At 2025-11-25 (and 2025-06-18), require the header on every POST after the initialize exchange.

mcpsnoop-origin-refusal-unmatched: check: the id-less error body of a 403 Origin refusal is reported as a response with no matching request

Version: mcpsnoop 0.26.1.

What happens. Streamable HTTP, 2025-11-25 or 2026-07-28. A POST arrives with Origin: http://evil.example.com; the server refuses it with 403 Forbidden and the body {"jsonrpc":"2.0","error":{"code":-32600,"message":"Forbidden: Origin not allowed"}}. check reports response id has no matching request on that error.

Expected. No finding. The transport’s security warning reads: “If the Origin header is present and invalid, servers MUST respond with HTTP 403 Forbidden. The HTTP response body MAY comprise a JSON-RPC error response that has no id.” The server refuses before it reads the request, so it has no id to echo, and the specification permits the body that results.

Suggested fix. When an id-less error is the body of a 403 answering a request that carried an Origin header, treat it as that exchange’s refusal rather than as an unmatched response.

The rule map

Each mcpsnoop rule, the message template that identifies it (* is any run), and the clauses it corresponds to; italic ids are partial. Fired counts traces where the rule fired and was not set aside. A rule no trace fires was read from the binary’s strings and is untested here.

Every trace