Feat/tasks mrtr extension

[panyam]

Summary

Adds server-conformance scenarios for SEP-2663 (Tasks Extension), with incidental coverage of SEP-2575 (per-request capability override) and SEP-2243 (Mcp-Method/Mcp-Name request headers) in the parts of the surface where they bind to tasks. Plus one new MRTR-adjacent check (mrtr-tasks-composition, currently SKIPPED) for the SEP-2663 commit 451f5e1 MRTR→Tasks promotion flow. 8 ClientScenario classes / ~33 internal checks for tasks plus 1 class / 7 SUCCESS + 1 SKIPPED for the MRTR↔Tasks composition placeholder. Tagged ['extension', DRAFT_PROTOCOL_VERSION] per #255 conventions and registered in pendingClientScenariosList so default everything-server runs stay green.

Motivation and Context

SEP-2663 (Tasks Extension), SEP-2575, and SEP-2243 are in active draft and currently have no conformance coverage in this repo. SDKs implementing them - including ones already shipping reference servers - have nothing to validate against, so wire-shape regressions and edge-case behavior (cancellation semantics, requestState handling, capability gating) slip
through SDK-internal tests. This PR fills that gap. The new scenarios assert what the spec text says, not what any specific implementation does, so any SDK can run them.

The MRTR↔Tasks composition placeholder (mrtr-tasks-composition, SKIPPED) is a forward-looking marker for SEP-2663 commit 451f5e1, which made the "MRTR rounds then promote to a task" flow normative on the wire - see the open spec questions below for why it's deferred.

How Has This Been Tested?

Run end-to-end against a reference Go fixture from the in-flight panyam/mcpkit SDK:

TASKS_SERVER_URL=http://localhost:18092/mcp \
TASKS_SERVER_CMD="/path/to/tasks-fixture --serve --addr :18092" \
MRTR_SERVER_URL=http://localhost:18093/mcp \
MRTR_SERVER_CMD="/path/to/mrtr-fixture --serve --addr :18093" \
  npx vitest run src/scenarios/server/

Branch results:

• Tasks: 8/8 scenarios (~33 internal checks)
• MRTR: 1/1 scenario (7 SUCCESS + 1 SKIPPED - see Open Question 2 in Additional Context)

The runner is brand-neutral and language-agnostic - fixture wired via env vars, spawn via sh -c, readiness via TCP polling, no log-line scanning. Anyone's server in any language works. Reference fixtures:

• https://github.com/panyam/mcpkit/tree/main/examples/tasks-v2 and
• https://github.com/panyam/mcpkit/tree/main/examples/mrtr.

npm test against the upstream everything-server continues to pass - the new scenarios live in pendingClientScenariosList so all-scenarios.test.ts skips them until everything-server grows extension support.

Breaking Changes

None. All new scenarios are additive and tagged as 'extension' + DRAFT_PROTOCOL_VERSION, so they're invisible to dated --spec-version runs and only appear under --suite extensions or --spec-version draft. Default CI runs against everything-server are unaffected (the new scenarios are filtered out via pendingClientScenariosList).

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

Relationship to PR #188 (SEP-2322 MRTR)

Complementary, not overlapping. SEP-2663 builds on SEP-2322's base types, so a few of the tasks scenarios touch the MRTR shape (inputRequests, requestState, resultType) in their tasks-on-the-wire form (status:"input_required" on tasks/get, tasks/update resume path, partial inputResponses fulfillment). The standalone-ephemeral-MRTR coverage stays in #188.

The branch also contains a src/scenarios/server/mrtr/ folder with ephemeral-flow scenarios mirroring some of #188's checks. Those exist because the tasks reference fixture exercises the full MRTR base, and running them locally caught a real bug. For this upstream merge:

• If Conformance Tests for SEP-2322 MRTR #188 lands first (expected order - SEP-2322 ships before SEP-2663), I'll drop the duplicative mrtr-ephemeral-flow.ts checks in favor of Conformance Tests for SEP-2322 MRTR #188's scenarios.
• The mrtr-tasks-composition check (currently SKIPPED) is the genuinely new contribution this PR makes to MRTR coverage.

Scope (8 ClientScenario classes, ~33 checks)

• tasks-lifecycle - sync vs task dispatch, DetailedTask shape, tool errors vs protocol errors, cancel ack, cancel-on-terminal -32602
• tasks-capability-negotiation - extension advertised under capabilities.extensions; tasks/* gated behind negotiation; SEP-2575 per-request opt-in
• tasks-wire-fields - ttlSeconds / pollIntervalMilliseconds renames, no early TTL expiry, no related-task _meta on inlined result
• tasks-request-state - optional emission, echo acceptance, stale-but-valid tolerance (tasks-surface form)
• tasks-mrtr-input - inputRequests on tasks/get, tasks/update resume, partial-fulfillment with multi-input fixture
• tasks-request-headers - SEP-2243 server tolerates routing headers; body authoritative when conflicting
• tasks-dispatch-and-envelope - removed v1 methods (-32601), legacy task param ignored, resultType:"complete" on every non-task response, strong-consistency immediate tasks/get, unknown taskId -32602
• tasks-status-notifications - optional INFO check (notifications are MAY per spec)

Plus mrtr-ephemeral-flow (1 class / 7 SUCCESS + 1 SKIPPED) under src/scenarios/server/mrtr/.

Design highlights

• Platform/Language agnostic runner. Fixture configured via env vars TASKS_SERVER_URL / TASKS_SERVER_CMD (and
  MRTR_SERVER_URL / MRTR_SERVER_CMD). Spawn via sh -c, readiness via TCP polling, no log-line scanning. Suite is
  describe.skip'd when env vars are unset.
• Raw-fetch escape hatch. SDK's typed schemas strip the SEP-2663 wire fields (resultType, taskId, inputRequests,
  requestState, inlined result/error). Helpers in src/scenarios/server/tasks/helpers.ts provide initRawSession +
  rawRequest/rawRequestFull so scenarios read those fields directly. When the SDK gains schemas for SEP-2663 shapes, the
  call sites switch back to client.request(..., AnyResult) and the helper shrinks. Similar in spirit to the raw-MCP
  additions in Conformance Tests for SEP-2322 MRTR #188 - could converge on a shared helper.
• Registered in pendingClientScenariosList - all-scenarios.test.ts skips them since everything-server doesn't
  implement the extension yet. CLI lookup (getClientScenario(name)) still finds them.

Open spec questions

1. MRTR resultType discriminator value. SEP-2322's draft uses "input_required"; SEP-2663's draft uses "incomplete". Centralized as MRTR_INCOMPLETE_RESULT_TYPE for a one-line flip when SEP authors converge. Tracked at modelcontextprotocol/modelcontextprotocol PR 2663 comment 4381885336 and PR 2322 comment 4381884825.

2. mrtr-tasks-composition. SEP-2663 commit 451f5e1 made the MRTR→Tasks promotion flow normative on the wire: a single tools/call MAY exchange one or more IncompleteResult rounds and then return CreateTaskResult on a subsequent round. Implementing this requires the server middleware to defer task creation until the handler signals async-promotion - the natural alternative (mint the task up-front the moment a tool advertises task support) doesn't fit, because by the time the handler's IsIncomplete signal is observable, the CreateTaskResult is already on the wire. This is a wire-contract requirement, not an SDK-specific implementation choice; existing SDKs across languages that took the up-front pattern will need refactoring before this check can pass anywhere. Combined with Adjust test and allow running in interactive mode #1 above, that's why the check is SKIPPED today.

Closes: #261

[panyam]

@LucaButBoring