feat: add client conformance tests for SEP-2575

[anubhav756]

Adds client-side conformance tests for stateless MCP (SEP-2575).

Note

This is a companion PR to the server-side tests in #271.

Context

SEP-2575 removes the initialize handshake and carries version and capabilities on a per-request basis. This PR adds the conformance tests required to verify that client implementations correctly follow these new stateless rules.

How Has This Been Tested?

I created the StatelessScenario in src/scenarios/client/stateless.ts and verified it locally:

1. Positive case: Added a stateless client flow to the example everything-client.ts. Running it against the harness passes all checks.
2. Negative cases: Added unit tests in stateless.test.ts to verify the harness correctly catches non-compliant clients that:
   • Omit the _meta parameter.
   • Flip protocol versions between requests.
   • Omit the MCP-Protocol-Version HTTP header.

All unit tests pass locally.

Breaking Changes

None.

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

None.

[pkg-pr-new]

Open in StackBlitz

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

commit: 18e3ecc

[pcarleton]

Thanks for tackling this. SEP-2575 is a big one. I ran /new-sep 2575 to build the full requirement-traceability YAML and opened it as #273 so we have a shared reference for both this PR and #271.

Coverage: the YAML has 12 client-side check: rows; this PR currently covers 3 (client-populates-meta, the version-header pair). The 5 stdio-only rows can be a follow-up scenario, but the 3 client-declares-{elicitation,roots,sampling}-capability MUSTs and the client-retry-supported-version SHOULD are HTTP-reachable and would fit nicely here.

Correctness bits:

• client-consistent-version — I couldn't find spec backing for this. SEP-2575 makes each request self-contained; nothing forbids a client from changing protocolVersion between requests. The flippingVersionClient negative test would fail a conformant client. Suggest dropping.
• client-cancels-by-notification — spec scopes notifications/cancelled to stdio only ("Streamable HTTP: …No notifications/cancelled message is required or expected"). This scenario is HTTP, so the check can't legitimately fire here.
• server/discover gap — the example's discover call (everything-client.ts:98) sends no _meta and no MCP-Protocol-Version header, but the harness marks it as passing. client-sends-version-header is guarded by if (currentVersion) and client-populates-meta runs after the discover early-return. I think we want the example to send the header and the check order to catch it if an example doesn't do it.
• Check IDs — we're shifting to check ids like sep-<NNNN>-<slug> (see sep-2164-error-code in resources.ts); renaming to match #273's slugs will let the traceability tooling line them up automatically.
• specReferences URLs are empty — #273 has the per-row anchors you can lift.

[pcarleton]

(See above)