feat: support "draft" as a first-class spec version target

[pcarleton]

Closes #253.

Problem

SEP authors testing against the in-progress spec can't run the full suite: the initialize check rejects draft protocolVersion strings, and --spec-version draft only selects the handful of explicitly draft-tagged scenarios (skipping initialize and the rest of the core suite). Tagging core scenarios with 'draft' is blocked by the spec-version isolation test.

Raised by @mikekistler in #conformance-testing-wg while testing SEP-2243.

Naming: 'draft' vs 'DRAFT-2026-v1' vs '2026-06-DRAFT'

There are two distinct namespaces in play, and the spec repo treats them differently:

Namespace	Spec-repo precedent	Used here
Docs / scenario tag	docs/specification/draft/ — the folder is literally draft, renamed to a date on release	SpecVersion = ... | 'draft' (unchanged)
Wire protocolVersion	schema/draft/schema.ts → LATEST_PROTOCOL_VERSION has cycled DRAFT-2025-v1 → -v2 → -v3 → DRAFT-2026-v1 (history)	DRAFT_PROTOCOL_VERSION = 'DRAFT-2026-v1'

So this PR keeps 'draft' as the conformance scenario tag (it's a folder alias, not a wire value, and survives release renames cleanly), and pins the exact current draft wire string as DRAFT_PROTOCOL_VERSION. We considered a permissive /^draft/i regex but rejected it: an SDK sending a stale DRAFT-2025-v3 is testing against a draft that no longer exists, and that should fail. The constant needs bumping when the spec repo bumps theirs — same maintenance model as LATEST_SPEC_VERSION. A '2026-06-DRAFT' form was also rejected: the spec repo doesn't use it anywhere and the release date isn't known in advance.

Changes

• types.ts: add DATED_SPEC_VERSIONS, LATEST_SPEC_VERSION, and DRAFT_PROTOCOL_VERSION constants plus specVersionToProtocolVersion(). Next spec release (or draft revision bump) is a one-line change here.
• checks/client.ts / scenarios/client/initialize.ts: accept DRAFT_PROTOCOL_VERSION as a valid protocolVersion (exact match — stale draft strings like DRAFT-2025-v1 are rejected). Mock server echoes it back.
• scenarios/index.ts: new matchesSpecVersion() helper. --spec-version draft now resolves to latest-dated ∪ draft-tagged — scenarios stay tagged draft-only, but selection treats draft as a superset of the current release.
• runner/client.ts / index.ts: forward the resolved wire version to the client process via MCP_CONFORMANCE_PROTOCOL_VERSION (e.g., --spec-version draft → DRAFT-2026-v1). Example clients can use this directly as their protocolVersion without maintaining their own mapping; SDKs that hard-code their version can ignore it.
• Tests: superset relationship + tag-level isolation asserted separately; positive test for DRAFT_PROTOCOL_VERSION, negative tests reject 'DRAFT-2025-v1' and bare 'draft'.
• README documents --spec-version and the new env var.

Behavioral note: tier-check

tier-check calls listScenariosForSpec (test-conformance-results.ts:208,264), so a tier-check run with --spec-version draft will now score against latest ∪ draft instead of draft-only. This is internally consistent (filter and expected-list both go through the same function) but means draft tier scoring is meaningful only as "would this SDK pass tier N if draft shipped today."

Testing

$ npx vitest run
Test Files  8 passed (8)
     Tests  116 passed (116)

Typecheck and lint clean.

Follow-ups (not in this PR)

• Range-based tagging — replace per-scenario specVersions: [...] lists with introducedIn / optional removedIn. The superset model in this PR can't express a SEP that tightens or removes an existing requirement (e.g., SEP-986 narrowed valid tool-name format) — there's no subtraction arm. Every spec release also currently requires touching every carried-forward scenario. matchesSpecVersion() is the seam where range logic slots in; the migration is mechanical across ~40 scenario declarations. ('extension' would stay an orthogonal flag since it's off the dated timeline.)
• Migrating remaining hard-coded '2025-11-25' literals in server scenarios to LATEST_SPEC_VERSION.

[pkg-pr-new]

Open in StackBlitz

npx https://pkg.pr.new/@modelcontextprotocol/conformance@255

commit: 78514c2

[felixweinberger]

LGTM, optional nit on consolidating a single constant instead of having 2 copies

[felixweinberger]

could consider consolildating a VALID_VERSIONS constant in types.ts instead of having 2 copies here and in client.ts

[felixweinberger]

feels like something worth cleaning up, spec vs protocolVersion might get more confusing over time the longer we have both of these 🤔

[pcarleton]

👍 we need a different way to refer to extensions, it doesn't super make sense to run "all extensions" as a selector. ties a bit into my comment on #114 about making it easier to selectively run scenarios via a config file

[mikekistler]

I'm confused. What protocol version should we be using for conformance tests of draft features? This one or "draft"? If it is this one, then why the special casing of "draft" for the --spec-version parameter?