Trace corpus

Fixtures for the golden-corpus tests (crates/mcp-trace-validator/tests/golden.rs):

• good/ — sessions that must validate with verdict pass, at the revision each declares: validate with no flags passes all of them but one, the session whose server answers initialize with 2024-11-05 (stdio-server-negotiates-2024-11-05), which validate refuses by default (exit 2) and passes with --revision 2025-11-25. The CI jobs that run the shipped Action and image over this directory name that exception.
• violations/ — single-issue sessions, each falsifying at least one check; named after the requirement whose check they exist to kill.
• draft/{good,violations}/ — the same two kinds for revision 2026-07-28, judged against that revision’s registry.
• draft/captured/ — sessions recorded off the wire from implementations this repository did not write. No verdict is asserted for them; their whole report is byte-pinned instead. See Captured versus authored below.
• captured/ — the 2025-11-25 counterpart: the official SDKs’ conformance servers recorded by interop/matrix.sh, judged against that revision’s registry, likewise pinned without an asserted verdict. Their 2026-07-28 sessions sit in draft/captured/ beside the others. See The official SDKs’ conformance servers below.
• golden/ — the byte-pinned expected report for every trace, with golden/draft/ holding the 2026-07-28 corpus’s. Regenerate only via cargo xtask bless and review the diff like code.
• golden/exclusions/ — one ledger per revision, holding the clauses that revision’s registry declines to judge from a trace, and why.

The revisions keep separate golden directories so that where a golden lives says which revision’s registry produced it. Trace names would not collide without the split: a requirement ID names one clause in one revision and is never reused (STABILITY.md), so base-045-… can only be a 2026-07-28 trace — BASE-045 is not a 2025-11-25 requirement. A sentence both revisions carry has an ID in each.

What a golden pins

A report states two kinds of fact, and they are pinned separately (ADR-0013).

golden/<stem>.json holds what the trace decided: the revision, the whole totals, and every pass / fail / warn / not-observed / not-applicable / unsupported row, in registry order.

golden/exclusions/<revision>.json holds what the registry decided: the excluded rows, whose outcome and prose come from the registry alone and are identical for every trace judged against it — engine::build_row never consults the session for them. One distinct set per revision, and before the split every golden restated its revision’s whole set: at the time that was 59% of the corpus’s lines.

Every cell is verified against the corpus by cargo xtask ci (xtask::coverage::corpus). It is checked rather than trusted because it had already drifted twice: this paragraph is prose, and prose does not recount itself.

Nothing stopped being pinned. Splicing a golden back together with its ledger reproduces the whole report, and assert_reconstructs_the_full_report proves it does on every trace, on every run — so a judged row that went missing, a ledger that drifted from its registry, or rows that interleave in any order but the registry’s all fail the suite. totals.excluded stays in every golden as the per-trace tie back to the ledger: a clause entering or leaving the excluded set moves every golden for that revision, one line each.

Only excluded collapses. not-observed and not-applicable are per-trace evidence, and the table’s third row is the measure of it: near one distinct set per golden, in both revisions. Collapsing those would delete exactly what makes the captures differentiate each other.

Violation naming contract

A violation trace is named area-nnn-<slug>.jsonl and must produce a Fail/Warn row with findings for exactly requirement AREA-NNN — the golden harness enforces the attribution by name (violation_traces_fail_and_match_goldens, and draft::draft_violation_traces_fail_and_match_goldens for draft/), so a defect re-routed to a different requirement cannot re-bless silently. A stem that does not begin with a requirement ID fails the suite loudly. The one other prefix is wire-schema-<slug>.jsonl: such a trace must fail the report’s wire schema — the messages against the revision’s own JSON Schema, which no requirement row carries (ADR-0020).

Captured versus authored

Everything in good/, violations/ and draft/{good,violations}/ is authored: hand-written to exercise one clause. That is what makes them precise, and it is also their limit — an authored fixture can only ever confirm its author’s reading of the specification. A check that is wrong in the same way the author is wrong passes its unit tests and its corpus alike, and neither notices.

draft/captured/ exists to close that gap. Its traces are real recordings of traffic between implementations neither of which was written to satisfy these checks, so they can disagree with us — and when they do, the disagreement is information rather than a test failure. Their goldens are pinned without any pass/fail expectation, because a real implementation is whatever it actually is; what the golden protects is which requirements fire, on which events, with what detail. A check that starts misfiring on real traffic moves it — which is precisely the half of the report that stays in the per-trace file.

Provenance ledger

Every trace’s origin, in one reviewable place that survives history rewrites (the invariant test in golden.rs fails if a trace is added without a ledger row). All current traces share one provenance: hand-authored for this repository as synthetic sessions (no third-party traffic, no recorded production data), written against the 2025-11-25 spec text fetched live from modelcontextprotocol.io on 2026-06-09 (re-verified clause-by-clause against the live text on 2026-06-11) and validated against the embedded registry at the commit that introduced them.

Traces under draft/captured/ are the exception and record their own origin below: the implementations on both ends, the tool that recorded them, and when.

good/

violations/

Each file injects exactly the violation its name states; golden/ shows every row the trace decided, including any intrinsic secondary findings the injected defect causes (a malformed notification also fails lifecycle accounting, for example).

2026-07-28 captured (corpus/draft/captured/)

Two recordings of the same client driving the same scenarios, differing in one variable: which revision the server was serving. That is what makes the pair worth committing — a single capture shows what one implementation does, while a matched pair shows what the revision costs, and every difference between the two reports is attributable to that one change.

Both carry server/discover, tools/list, tools/call, completion/complete, resources/{list,read}, prompts/{list,get} and progress notifications; every request carries the revision’s per-request _meta envelope and its SEP-2243 metadata headers, and neither carries an initialize anywhere. Their tools/list results differ by two entries, which is the point of recording both: test_url_elicitation and test_list_changed are listed by the legacy server (18 tools) and not by the stateless one (16), because what each tool does has no place at 2026-07-28: that revision removed notifications/elicitation/complete and URL mode’s elicitationId (URL-mode elicitation itself remains), and moved list_changed notifications into subscriptions. Each listing is the first page; neither session follows nextCursor.

The one finding left: BASE-037, a warning, on the legacy leg. Of that server’s 24 results only the server/discover one carries io.modelcontextprotocol/serverInfo in its _meta; rmcp sets it there and on subscriptions/listen and nowhere else. The stateless server names itself on all 24, as it has since 2026-10-13. The legacy server is left without the field on purpose: it implements 2025-11-25, which names the server once, in initialize, and the measurement is that server held to a revision it does not implement (ServedRevision::names_itself_on_results). It is a SHOULD that exempts a server “specifically configured not to”, so it warns and never fails a run. The same warning stands on every other rmcp server that does not add the field itself (sdk-rust-2026-07-28); the Go and Python SDK servers set it on every result (sdk-go-2026-07-28, sdk-python-2026-07-28).

Two findings that used to be here were ours, not the implementations’. An earlier version of this pair reported TRAN-058 (client POSTs missing Mcp-Method/Mcp-Name) and TRAN-068 (SSE responses missing X-Accel-Buffering: no). Both were artifacts of the tap’s recording allowlist, which predated SEP-2243 and did not record those headers — the client sent them (rmcp’s transport rejects a 2026-07-28 request without Mcp-Method before dispatch, and the suite scored 23/23) and the server sent them (rmcp sets X-Accel-Buffering on every SSE response it builds). The allowlist was extended; both clauses now pass on both captures. The lesson is recorded rather than quietly fixed: a check can only be as honest as the recording it reads, and a capture path that silently drops evidence manufactures findings against conforming implementations.

The same lesson, a third time, one field over (2026-08-20). The tap recorded an exchange’s headers but not its method, so TRAN-025 and TRAN-039 — the Accept obligations of a POST and of a GET — were enforced as one rule applied to every client request whatever its form. That was wrong twice over, and both halves were found by pointing this workspace’s own reference host at its own reference server over HTTP and validating the tap: the conforming session-teardown DELETE, which owes no Accept header at all, drew two MUST-level failures, while a POST omitting application/json — the verbatim violation TRAN-025 names — was reported pass, because the one shared rule could only demand what both clauses had in common. EventBody::Http now carries the method, each clause is judged against the requests it binds, and an exchange whose method the capture did not record is judged by neither. These two captures were re-recorded on 2026-08-20 so the method is present, on 2026-10-04 when the draft ratchet moved to alpha.12, and on 2026-10-13 (below).

Why the runner’s 23/23 and our 59-vs-60 were both right — and how the runner caught up. The suite’s 2026-07-28 scenarios exercise features — list a thing, call a thing, read a thing — and a 2025-11-25 server answers all of them, because rmcp serves a per-request-versioned POST whichever revision the handler advertises. At 0.2.0-alpha.9 that was the whole of the runner’s reading, so it scored both servers 23/23. The registry here judges the specification’s prose instead, so it saw the one place the two servers actually differ: CACH-001, no ttlMs on cacheable results.

0.2.0-alpha.11 found the same thing, six weeks later. Its new wire-schema-valid check validates every message against the negotiated revision’s JSON schema, and it fails the 2025-11-25 leg’s four resource scenarios for must have required property 'cacheScope' / 'ttlMs' — that clause, independently. Measured at alpha.11, the legacy leg scored 37 passing / 4 failing and the stateless leg 41 / 0, so the runner separated the two servers it could not tell apart before. Neither instrument was wrong; they were measuring different things, and one of them saw this first. The pair is still the evidence for taking both readings — now with a worked example of the prose-level reading arriving earlier than the schema-level one.

And then the implementation closed the gap. rmcp 3.5.1 fills in missing cache hints for any peer speaking 2026-07-28 (rust-sdk #1308), so since the workspace moved to it (2026-10-12) the legacy server’s results carry ttlMs and cacheScope too (ttlMs: 0 on resources/list, rmcp’s default rather than this server’s choice), and cargo xtask draft-readiness scores both legs 42 passing / 0 failing. The pair was re-recorded on 2026-10-13, so the legacy leg no longer fails CACH-001 or the wire schema; until then it was kept as recorded on 2026-10-04 (69 pass, CACH-001 failing; the runner 38 passing / 4 failing), and this section’s history above is the evidence for what each instrument caught and when. With the hints filled in, the runner again scores both servers alike, and only the registry’s BASE-037 warning tells them apart.

The 110 not-observed rows are the honest denominator: of the 181 clauses this revision’s registry can judge, these sessions carried subject matter for 71. They open no subscription, present no cursor, draw no JSON-RPC error, and send no malformed _meta, so those clauses are neither passed nor failed here — they are untested, and the report says which.

Regenerate both with cargo xtask draft-readiness and copy target/draft-readiness/<revision>/tap/001-stateless.jsonl; the ephemeral port in the host header changes per run, so re-copying is a deliberate act with a golden diff, not something to do casually.

The stdio capture

It is the only capture that exercises subscriptions/listen. The official suite drives no subscription, so the four judged SUBS clauses — and BASE-039, which binds a subscription stream’s notifications — are backed by this file alone: an acknowledgment, a filter the server narrowed, four tagged notifications and an empty graceful-closure result. The same holds for the MRTR clauses. In the two HTTP captures every one of those rows now reads not observed; here they read pass.

Two defects were found by enriching it, and neither could have been found any other way. Until the session read a resource the catalog does not have, nothing in this workspace had ever exercised the server’s not-found path at this revision — and it answered -32002, which 2026-07-28 withdraws outright (basic/index#error-codes lists it under “Implementations of this protocol version MUST NOT emit these codes” and names -32602 as the replacement). The second was ours: the host’s recorder assigned seq when the send future completed rather than when the message was handed to the transport, so a reply received while that future was still pending landed in the trace ahead of its own request. That reads as the server answering an id nobody asked, and it failed BASE-046 on roughly one capture in three. Both are fixed, both have regression tests, and both are the argument for driving more traffic rather than more fixtures.

That asymmetry is the reason to keep all three, and it used to be invisible. Until the vacuous-pass fix, those rows read identically across the three files — pass everywhere, whether or not the session had opened a stream — and this paragraph recorded that as a known reporting limitation. It is a limitation no longer: every check counts the subjects it examined, so a clause with nothing to look at reports not-observed. Read in the other direction, the captures are complementary rather than redundant: the HTTP pair evidences the transport header and status clauses, which no stdio recording can carry, and this one evidences the subscription, MRTR, prompts, resources, logging, completion and error-code clauses, which theirs never reach.

What the 48 not-observed rows still are, and why. Thirty-three are Streamable HTTP mechanisms a stdio recording structurally cannot carry: twenty-five clauses of the TRAN-056…TRAN-102 band (it holds 27 judged clauses, and the two a stdio session does reach, TRAN-060 and TRAN-066, are judged here), the seven rows of the x-mcp-header behaviour table (TRAN-130…TRAN-136), and TOOL-034 — header mirroring is an HTTP mechanism, and “Clients using other transports (e.g., stdio) MAY ignore x-mcp-header annotations entirely”. Eight are server rejection rules — BASE-031, BASE-032, BASE-035, BASE-036, VERS-001, VERS-002, VERS-008, LOG-010 — reachable only by a client that deliberately sends something malformed, which this session does not: it is the conforming capture, and a probe session is a separate recording with a separate expected report. Two, CANC-003/CANC-011, bind a server that sends notifications/cancelled, and this one ends every subscription gracefully instead. TOOL-022 is the interesting one: rmcp’s client caches tools/list under the server’s own ttlMs, so a second listing never reaches the wire — a conforming client cannot exercise the deterministic-order clause within the TTL, which is a property of the caching feature working rather than a gap to close (the official suite’s runner does not cache, and judges it on both of its captures). The remaining four are not driven by this host: TRAN-128 and DISC-002’s dual-era probe, MRTR-024, and VERS-004.

The client-feature pages added twelve more on 2026-10-13, on both legs (review item 2.5). The session’s one sampling round carries no tools, so nothing it sends exercises the tool-use clauses (SAMP-026, SAMP-030…SAMP-033, SAMP-042) or the deprecated includeContext permission (SAMP-029); it asks for no roots (ROOT-013, ROOT-014, ROOT-018), and none of its elicitations is in URL mode (ELIC-064, ELIC-065). The three form elicitations and the sampling round are judged. When they were first judged one of them warned: ELIC-095 (“Clients SHOULD validate all responses against the provided schema”) on the host, whose AcceptWithDefaults policy answered the probe form — username and email required, neither with a default — with accept and empty content. That was a finding against this project’s own client, on both legs, not a reading the text leaves open, and it was fixed the same day: the policy now fills each required field without a default with a deterministic value of its type ("scripted" for both of these plain strings), and declines a form whose required fields no value can satisfy rather than accepting it with content the schema rejects (mcp_reference_host::script::accepted_content states the rule). Both legs were re-recorded with the fix and pass it.

Five used to be on that list for want of server surface; four have left it. CACH-015/CACH-016 needed a catalogue served in pages and PROM-017 a prompt carrying audio, and both are on the listings’ second pages now; TOOL-033 needed an x-mcp-header designation, and judges it as listed, which any transport carries (TOOL-045 passes beside it). The fifth, TOOL-034, is in the HTTP group above: the designation exists now, and only the transport keeps it unobserved here.

The HTTP capture of the same session

Recorded by the server, not the host, and that is the whole point. The host’s recorder sits at rmcp’s Transport seam, which carries protocol messages and nothing else — redaction by construction, and no HTTP framing to record even if it wanted to. So a host-side HTTP recording would report the Streamable HTTP clauses as not observed exactly like the stdio one. The server’s tap sits above the transport and sees the status line and the conformance-relevant headers, which is why this leg is the only recording in the corpus that can bear on them at all. Same session, both ends, one file each: the difference between the two reports is attributable to the transport and to nothing else.

At 125 of the 181 judgeable clauses it is the best-covered capture here, and the fourteen it gained on 2026-10-13 are the server’s own doing: the second pages carry the pagination clauses (CACH-015/CACH-016), the audio prompt (PROM-017), and a tool designating three arguments for Mcp-Param-* mirroring, which rmcp’s client mirrors when the tool loop calls it — two supplied and mirrored, one left out and not, which is the header table’s “value provided” and “not in arguments” rows from both sides (TOOL-033, TOOL-034, TOOL-045, TRAN-079…TRAN-082, TRAN-130, TRAN-134, TRAN-135, TRAN-137). Its 33 not-observed rows are the fourteen rejection rules only the probe exercises, seven clauses judged on the stdio leg and not on this one (CANC-005, PROG-005, PROG-008, TRAN-117, TRAN-118, TRAN-123, TRAN-124), TOOL-022 (rmcp’s client caches tools/list under the server’s own ttlMs, so a second listing never reaches the wire), VERS-004, which only the Rust SDK’s capture evidences, and the ten clauses no capture reaches, each with its reason under What the captures evidence, together.

The probe session

A conforming client cannot exercise a rejection rule. The clauses of this revision that say what a server owes a request it must not serve all reported not observed on every recording here, because nothing had ever sent such a request. This file is that request, ten times over.

The probes are built outside rmcp, and that is the point rather than a shortcut: rmcp’s client is what makes the other captures trustworthy — it builds the _meta envelope, mirrors the SEP-2243 headers, and will not emit an ill-formed request — so it is structurally incapable of being the probe. The bytes here are the fixture.

Its verdict is a ledger, not a pass. The probe breaks client-side clauses by construction: BASE-030 because its first request omits a required _meta field, TRAN-071/TRAN-072 because two probes are about exactly those headers, TRAN-079/TRAN-130 because the last one leaves out the header whose absence TRAN-136 obliges the server to reject. Demanding a clean report would mean demanding a probe that probes nothing. So every finding is listed in conformance/probe-baseline.json with a reason, and the gate holds the set in both directions: a finding not in the ledger is a new defect or a regression, and a listed finding that stopped occurring is either a fix that should retire its entry or a check that quietly stopped firing.

It has already worked in both directions. The first probe run drew two server-side findings — the server served a request naming log level "chatty", and honoured a cursor it never issued — which went into the ledger as open defects. When they were fixed, the gate refused the change until their entries were retired, which is the half of a ratchet that is easy to leave out. A third went the same way on 2026-10-13: BASE-037 entered the ledger as an open server-side warning the day the clause became judged, and its entry was retired in the change that put serverInfo on every result. Every rejection clause the probe reaches now passes; fourteen clauses pass on this capture and on no other (BASE-031, BASE-032, BASE-035, BASE-036, LOG-010, TRAN-073, TRAN-074, TRAN-075, TRAN-098, TRAN-102, TRAN-136, VERS-001, VERS-002, VERS-008). The fabricated cursor is still sent, and judged by nothing: on 2026-10-04 PAGE-010 and PAGE-011 were excluded at this revision, because its caching rules make a cursor issued before the recording began a valid one (the registry entries record the reasoning). The server still refuses it, and a_fabricated_cursor_is_refused_on_the_stateless_revision in mcp-everything-server’s tests holds it to that.

Its provenance is weaker than the pair above, and deliberately labelled so. Both ends of this session are ours: the official suite drives servers over --url only, so there is no third-party client for stdio to be recorded against. What it still supplies that an authored fixture cannot is that neither end was written to satisfy these checks, and that the machinery producing every byte — the stateless lifecycle, the _meta envelope, the MRTR retry loop — is rmcp’s, not this repository’s.

It is also the only capture that judges a verdict rather than pinning a report. cargo xtask draft-capture fails on any finding, because a finding in a session where both ends are ours is a defect here rather than news about somebody else’s code. Regenerate with BLESS=1 cargo xtask draft-capture (which rewrites this file) followed by cargo xtask bless.

That gate was red for part of 2026-10-13, on two warnings, and is clean again. BASE-037 became judged that day, and this server — rmcp’s result types — named itself in _meta.io.modelcontextprotocol/serverInfo only on its server/discover and subscriptions/listen results; the client-feature pages added ELIC-095 against the host (above). The gate was left red rather than loosened until both were fixed here: the everything server now puts serverInfo on every result it builds at 2026-07-28 (mcp_everything_server’s private server::identity module, applied at each handler’s return beside the caching hints), and the host’s form answers satisfy their schema. Both reference-host captures and the probe were re-recorded with the fixes, and the probe baseline’s server-side BASE-037 entry was retired in the same change.

What it caught. The first recording of this session reported six failures the HTTP captures could not: TRAN-060/066/119/120 and MRTR-001, because the interactive tools still sent elicitation/create and sampling/createMessage as independent server-to-client requests — the mechanism SEP-2322 replaced — and LOG-008, because the logging tool emitted notifications/message for a request that had not asked for them. The official suite’s 2026-07-28 scenarios exercise no interactive tool and no logging tool, so an HTTP-only corpus would have shipped both defects. That is the argument for capturing both transports rather than treating one as representative.

What the captures evidence, together

The table below is generated from the committed golden reports by cargo xtask draft-coverage and verified by cargo xtask ci — per ADR-0001 these numbers are a projection of the data, not prose anyone maintains. The same gate parses every count stated elsewhere in the living Markdown — the “N of the M judgeable clauses” claims and the “N pass, M fail” verdicts alike — and fails when one disagrees, which is how the counts in this section stopped being wrong. A number quoted rather than asserted goes in backticks, and is read as a specimen instead.

Across all 9 captures, 148 of the 181 judgeable clauses are evidenced by at least one recording. Each capture’s own judged count is what that recording carried subject matter for; everything else it reports not observed rather than counting it as a pass.

The 33 clauses no capture reaches: AUTH-097, AUTH-124, AUTH-129, AUTH-130, AUTH-131, AUTH-132, AUTH-133, CANC-003, CANC-011, DISC-002, ELIC-064, ELIC-065, MRTR-024, ROOT-013, ROOT-014, ROOT-018, SAMP-026, SAMP-029, SAMP-030, SAMP-031, SAMP-032, SAMP-033, SAMP-042, TOOL-035, TOOL-046, TRAN-061, TRAN-070, TRAN-083, TRAN-084, TRAN-096, TRAN-128, TRAN-132, TRAN-133.

The probe session closed the largest group — the rejection rules — and the cancellation round closed the next. The official SDKs’ conformance servers (below) closed six more without a line of this repository changing: each of the three that serve this revision lists a tool carrying an x-mcp-header designation, which TOOL-033, TOOL-045, TRAN-080, TRAN-082 and TRAN-137 judge, and the Rust SDK’s declares an extension, which VERS-004 judges.

The reference server’s own surface closed ten more on 2026-10-13. Every listing is now served in two pages — the suite’s catalogue first, then what the suite does not name — and both captures of the host follow nextCursor: the pages are CACH-015/CACH-016’s subject, and the second prompt page carries audio for PROM-017. A second-page tool designates three arguments for Mcp-Param-* mirroring, and the host’s tool loop calls it over HTTP with two supplied and one left out, so rmcp mirrors two headers and omits the third (TOOL-034, TRAN-079, TRAN-081, TRAN-130, TRAN-134, TRAN-135). The probe then sends the same call with one header missing, which the server must refuse and does (TRAN-136).

What is left — 33 clauses — is not backlog in the ordinary sense; each stays for a reason a richer session would not remove. Ten are the transport and lifecycle clauses below; the other 23 came with the client-feature and authorization pages and are grouped after them.

Two are out of an rmcp client’s reach: TRAN-132/TRAN-133, the behaviour table’s “Parameter value is null” row. A client can only send null for a designated argument whose schema admits it, and rmcp’s client drops any tool whose designated property’s type is not a single primitive — ["string", "null"] included — so a nullable designation never reaches an rmcp client’s call, and this host synthesizes only required arguments and never a null. The row’s pass path is authored (good/http-x-mcp-header-omitted.jsonl), and the rmcp restriction is a candidate to raise upstream.

One cannot be recorded by the server’s tap: TRAN-096, a recognized Mcp-Param-… header holding invalid characters. HTTP parsing strips a value’s edge whitespace before any handler sees it, and the tap records only values that decode as visible ASCII — rmcp likewise reads anything else as no header at all, and refuses the call as a missing one — so the antecedent never reaches the recording however the request is built. Authored traces carry both halves (draft/violations/tran-096-invalid-param-header-accepted.jsonl, draft/violations/tran-077-param-header-value-rejected.jsonl).

Three belong to a client no capture has: TRAN-061 needs a client to POST a notification over Streamable HTTP, and no 2026-07-28 capture contains one — rmcp’s stateless client cancels by closing the response stream, and neither the official runner nor the SDK client sends any. DISC-002 and TRAN-128 need a dual-era client that probes before falling back to initialize, and this host speaks only the stateless revision.

Two need server behaviour this one does not have: CANC-003/CANC-011 bind a server that sends notifications/cancelled, which at this revision may only tear down a subscriptions/listen stream. This server ends every subscription gracefully instead — the closure SUBS-005/SUBS-006 judge, and pass — so tearing one down by cancellation would be a second closure path, added to light up a check; the pass path is authored (good/subscription-server-teardown.jsonl).

One cannot be reached by a conforming host at all, and saying so is more useful than closing it. MRTR-024 is a server re-asking after a client’s shortfall, and a retry that omits requested input is the client violation MRTR-015 names: driving it would make the reference host non-conforming, which is the one thing this capture may not be. It is evidenced by an authored violation trace instead, where the fault belongs. VERS-004 used to be its pair — a capture would have to declare an extension, and this host implements none, and declaring one only to light up a check is precisely the vacuous evidence the corpus exists to avoid. The Rust SDK’s conformance server declares one of its own accord, and that is evidence.

One is a recording gap rather than a session gap: TRAN-070 needs a response stream to close mid-session, and the server’s tap records no lifecycle events at all, so no HTTP capture can carry one however the session is driven.

Seven need a protected server: AUTH-097, AUTH-124 and AUTH-129–AUTH-133 read a WWW-Authenticate challenge, and no committed capture is of a server that requires authorization. Authored traces carry each (draft/violations/auth-*).

Four need a server that advertises a malformed x-mcp-header: TOOL-035, TOOL-046, TRAN-083 and TRAN-084 bind a client to reject such a tool and never call it. This server advertises only what it implements, and every designation it serves is valid, so no client of it has anything to reject. Authored traces carry both halves (tran-082-invalid-tool-excluded-valid-called, tran-083-invalid-tool-called).

Twelve need a client feature no captured session uses. No capture carries a URL-mode elicitation (ELIC-064, ELIC-065): the everything server’s only one is test_url_elicitation, which it does not offer at 2026-07-28, and the SDK servers send none. The one sampling request captured is plain (no tools, no includeContext), so tool-enabled sampling and its toolChoice and result-pairing rules (SAMP-026, SAMP-029–SAMP-033, SAMP-042) are unreached. No server in any capture sends roots/list, so ROOT-013, ROOT-014 and ROOT-018 are too. Each has an authored violation trace under draft/violations/.

BASE-047 used to be on this list. It left without a trace being written, because it was never a corpus gap: the check behind it counted only malformed responses as subjects, so every capture full of well-formed results reported the clause not observed — the tool saying it had seen nothing to judge about a session that had carried dozens of them.

The official SDKs’ conformance servers (captured/, draft/captured/)

Nine recordings of the Tier 1 SDKs’ own conformance servers (the TypeScript SDK’s two lines are two servers) — the server its maintainers run the official suite against — driven over Streamable HTTP by an official SDK client. Neither end is ours: this repository supplies only the recorder and the judge. They are the evidence behind the book’s cross-SDK matrix, which cargo xtask sdk-matrix generates from their goldens; the verdicts and counts live there, once, and are not restated here.

The trace bytes are not reproducible, and are not normalized. Each server mints a fresh session id on every run, and nothing is rewritten after recording — a recording edited after the fact is no longer a recording. What is held fixed instead is everything that changes a result: the ports (the proxy records the Host header), the client script, the pins, and the one race the session had. The TypeScript client opens its standalone GET stream in the background, and while that GET and the next POST both awaited a status the validator — correctly — attributed neither, so TRAN-040 read not observed on some runs and pass on others; the client now waits for the GET to be answered before its next request. Five consecutive local runs then produced identical reports, seq for seq. The weekly comparison ignores a finding’s seq all the same, because a session whose replies land a line apart is the same session.

Regenerate with interop/setup.sh and interop/matrix.sh, then BLESS=1 cargo xtask sdk-matrix --recaptured interop/out-matrix, cargo xtask bless, cargo xtask sdk-matrix and cargo xtask draft-coverage, and review the golden diff.

2026-07-28 authored (corpus/draft/)

Fixtures for revision 2026-07-28, judged by its registry. Hand-authored rather than captured, so each is a minimal trace written to exercise one clause, which is what keeps a violation attributable to the check it kills. Recorded 2026-07-28 sessions are in draft/captured/ (above), and the interop job records the official Python SDK’s client and server at that revision and requires them to judge clean (interop/README.md).

Where a trace falsifies more than one requirement, the row says so and why. There are only three reasons, and none is sloppy authorship: several clauses state one rule across several sections and share a check by design, one clause’s antecedent is itself a violation by the other party — a server can only fail to reject a bad header if the client sent one — or the shape a trace exists to carry is a violation in its own right: an HTTP answer with "id": null that the framing ties to its request is BASE-052’s whenever that request’s id could be read. Every other row falsifies exactly the requirement it is named for.

Every result names its server, and every request its client (2026-10-13). When BASE-033, BASE-037 and DISC-003 stopped being excluded, the authored traces were brought up to the two SHOULDs they had been written without: each result answering a request under the per-request envelope gained _meta.io.modelcontextprotocol/serverInfo (corpus-server 0.1.0), and the eight violation traces whose requests lacked clientInfo gained it. Nothing else in any trace changed, and no other row’s outcome moved; without the edit every authored trace would carry a warning unrelated to the clause it exists for. The three traces named for those clauses are the only ones left without.

Every form elicitation carries its schema (2026-10-13). When the client-feature pages entered the registry (review item 2.5), seven authored traces were found asking for form mode elicitation without the requestedSchema the page requires, or with no parameters at all — fixtures written for MRTR clauses that never needed one: mrtr-004, mrtr-015, mrtr-016-request-state-not-echoed, mrtr-018, mrtr-024, tran-066 and base-034-input-request-for-undeclared-capability. Each gained the same message and requestedSchema; nothing else changed. The wire schema had been failing all but the last of them for the omission, unrelated to the clause each exists for; it now passes them, and no existing requirement’s outcome moved.

Extensions at 2026-07-28 (corpus/draft/, ADR-0023)

Fixtures for the tasks (io.modelcontextprotocol/tasks) and skills (io.modelcontextprotocol/skills) extensions, hand-authored like the rest of corpus/draft/ and judged by the 2026-07-28 registry, whose extension clauses report in each report’s extensions block and never move its verdict. Every violation trace here leaves the core verdict pass unless its row says otherwise, which is the separation the corpus exists to show: the extension’s own verdict fails, the report’s does not. A task-… or skill-… trace is named for the extension clause it falsifies, and the golden tests look for that row in the extension block.