modelcontextprotocol / modelcontextprotocol/conformance
tier-check: final 2026-07-28 is still treated as draft and legacy scenarios score by default
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 127
- Forks
- 101
- Avg merge
- 6d 1h
- Merged PRs (30d)
- 7
Description
Summary
The current conformance main (49103de6ed70804e940637bf3e9e29e4a3f54e64) predates the final MCP 2026-07-28 release (modelcontextprotocol@5f5440bb26a62e2cf3440b92da5a667efa03b267) and still classifies 2026-07-28 as the draft protocol version rather than a dated release.
That makes current Tier checks misleading in two directions:
- An explicit
--spec-version 2026-07-28run does not score the complete final profile. - A default run scores removed legacy scenarios that are outside the SDK's target spec profile.
This was reproduced against leehack/mcp_dart@629a85c511913e30945568c6c27702da6760a3bc with @modelcontextprotocol/conformance built from 49103de6ed70804e940637bf3e9e29e4a3f54e64.
Current behavior
src/types.ts currently has dated versions ending at 2025-11-25, LATEST_SPEC_VERSION = '2025-11-25', and DRAFT_PROTOCOL_VERSION = '2026-07-28'.
For an explicit final-2026 run:
- The client executes 32 applicable scenarios, but the 17 introduced in
2026-07-28are marked informational. Only 15 scenarios affectpass_rate. - The server's default
activesuite excludes scenarios introduced in2026-07-28. It runs 20 scenarios instead of the 37 applicable non-pending scenarios (40 applicable, 3 pending). - The output can therefore report Tier 1 without assessing all final-2026 requirements.
For a default run with no --spec-version:
- Client tier-check invokes
--suite all. - Two optional March 2025 OAuth backcompat scenarios with
removedIn: '2025-06-18'enter the scored denominator. - Those scenarios are also run with the latest default wire version rather than a version inside their applicability window.
- In this reproduction, required current-profile scenarios passed, but those two removed scenarios reduced the displayed client rate from 100% to 18/20 (90%) and the aggregate result from Tier 1 to Tier 2.
The Tier policy says scores should use the SDK's target specification and exclude legacy backcompat unless the SDK claims it: https://modelcontextprotocol.io/community/sdk-tiers
Schema drift
src/spec-types/SOURCE currently pins pre-final spec commit 71e306956a4959c9655e5036be215d41986596e6, and scripts/sync-schema.ts vendors only the older dated schemas plus mutable draft.
The final 2026-07-28 schema includes changes completed before the final tag, including the SubscriptionsListenResultResponse envelope from modelcontextprotocol/modelcontextprotocol#3158. Final-2026 validation should use an immutable vendored schema/2026-07-28, not the pre-final draft snapshot.
Expected behavior
- Treat
2026-07-28as a dated, latest, Tier-scoring release. - Make the default Tier conformance target the latest dated release, while retaining explicit older-profile assessment.
- Exclude removed legacy scenarios and extensions from the default target profile; keep them selectable for intentional compatibility/extension testing.
- Include all applicable, non-pending final-2026 client and server scenarios in the scored assessment.
- Vendor and route final-2026 wire validation to the immutable final schema.
- Preserve a useful
drafttarget even while the spec repository's draft wireprotocolVersionis temporarily identical to the latest final date.
Proposed implementation direction
One coherent change could:
- Add
2026-07-28to the dated versions and make it latest. - Represent whether there is a distinct unreleased draft separately from the draft wire identifier, deduplicating the version timeline and negotiable versions while both identifiers match.
- Keep the draft suites empty until a distinct unreleased draft exists, so final-introduced scenarios become active and scored.
- Default tier-check conformance to
LATEST_SPEC_VERSIONinstead of the aggregateallsuite. - Vendor
schema/2026-07-28at the final tag and route dated validation to it.
The important design question is whether maintainers prefer this small has distinct draft model or a larger separation between CLI spec targets (draft versus dated releases) and wire protocolVersion values. I am happy to implement the agreed direction with inventory, tier-output, schema-routing, and backward-profile regression tests.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with src/types.ts to trace dated, draft, latest, and negotiable version handling, then inspect scripts/sync-schema.ts and src/spec-types/SOURCE for schema routing. Reproduce the explicit and default tier-check cases described in the issue. Done means final-2026 scenarios are scored, removed scenarios are excluded by default, and the immutable final schema is used while older profiles remain selectable.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, testing-qa, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100