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

[leehack]

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.

[leehack]

To provide more context beyond the AI-generated issue, I'm currently working on the mcp_dart project for Dartlang. My goal is to elevate its status to Tier 1. I believe it's ready for the SDK aspect, but the conformance package doesn't seem ready for the tier check with the new specification.

Although the tier system is for official SDKs, I still want to make sure this is ready for Tier 1 status. (Ideally, promoting it to an official SDK would be fantastic.)