PR #2911 - modelcontextprotocol/python-sdk

Adds a --spec-version 2026-07-28 carried-forward leg to the conformance workflow (one extra step in each of the existing server/client jobs) with its own baseline file, and bumps the harness pin to 0.2.0-alpha.4. No new jobs, no second everything-server, no second client — same fixtures, same run-server.sh.

Motivation and Context

The existing --suite draft step only runs scenarios introduced in 2026-07-28. It doesn't re-run the 2025-era scenarios (tools-list, prompts-get-*, resources-*, …) at the 2026 wire, so a regression where a previously-working feature breaks under the stateless protocol wouldn't be caught. --suite all --spec-version 2026-07-28 runs every applicable scenario at the 2026 wire and is the same shape typescript-sdk is adopting on its v2-2026-07-28 branch.

The 2026 leg needs its own expected-failures.2026-07-28.yml because baseline entries are keyed by scenario name only: a scenario that passes at its default version in the 2025 legs but fails when forced to 2026 (almost all of them today, since main has no stateless path) can't share a file with the 2025 legs — the passing leg would flag the entry stale.

This lands the CI infra ahead of the stateless implementation work so those PRs can rebase onto it and burn the 2026 baseline down per milestone, instead of each one re-deriving the workflow shape.

How Has This Been Tested?

Ran all five workflow steps locally against a build of @modelcontextprotocol/conformance@0.2.0-alpha.4 (built from the v0.2.0-alpha.4 release commit 7a620cb):

Leg	Result
`server --suite active --expected-failures expected-failures.yml`	exit 0, 42/42
`server --suite draft --expected-failures expected-failures.yml`	exit 0, 17 expected failures
`server --suite all --spec-version 2026-07-28 --expected-failures expected-failures.2026-07-28.yml`	exit 0, 38 expected failures
`client --suite all --expected-failures expected-failures.yml`	exit 0, 16 expected failures
`client --suite all --spec-version 2026-07-28 --expected-failures expected-failures.2026-07-28.yml`	exit 0, 27 expected failures

The alpha.3 → alpha.4 bump required no entry changes to the existing expected-failures.yml (only the version string in the header comment).

Breaking Changes

None — CI-only.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

Additional context

client.py now reads MCP_CONFORMANCE_PROTOCOL_VERSION (always set by the harness; defaults to its LATEST_SPEC_VERSION when --spec-version is omitted) into a module-level PROTOCOL_VERSION and logs it. No handler branches on it yet — the 2026 client leg is fully baselined until the stateless client path lands and adds the branch it actually needs.
run-server.sh already forwards "$@" to npx … server, so it needed no change for --spec-version.
The conformance composite action (action.yml) doesn't expose a spec-version input; we invoke via npx so that doesn't affect us, but it's worth a follow-up upstream.

_{AI Disclaimer}