modelcontextprotocol / modelcontextprotocol/conformance

tier-check: final 2026-07-28 is still treated as draft and legacy scenarios score by default

Open
#426 1 comment 0 reactions 0 assignees View on GitHub

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:

  1. An explicit --spec-version 2026-07-28 run does not score the complete final profile.
  2. 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-28 are marked informational. Only 15 scenarios affect pass_rate.
  • The server's default active suite excludes scenarios introduced in 2026-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-28 as 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 draft target even while the spec repository's draft wire protocolVersion is temporarily identical to the latest final date.

Proposed implementation direction

One coherent change could:

  1. Add 2026-07-28 to the dated versions and make it latest.
  2. 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.
  3. Keep the draft suites empty until a distinct unreleased draft exists, so final-introduced scenarios become active and scored.
  4. Default tier-check conformance to LATEST_SPEC_VERSION instead of the aggregate all suite.
  5. Vendor schema/2026-07-28 at 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.