Task-augmented MCP tool calls (CreateTaskResult / tasks/result) — #96 acceptance remainder

[ScriptedAlchemy]

Why this exists

The closed-issue audit of #96 found one acceptance criterion that is neither met nor tracked anywhere:

Ordinary MCP calls receive optional progress notifications followed by one final CallToolResult. Task-augmented calls receive a CreateTaskResult first and retrieve that final result through tasks/result. Neither mode encodes partial content in progress messages.

The ordinary-call half landed in #175 (projectMcpRenderStream, progress-token gating, one final CallToolResult). The task-augmented half was noted in #175 as "post-stage-4" and the #96 closing summary said it "should open as focused follow-ups if needed" — no follow-up was opened. On origin/main (af1c18551) there is no tasks/get, tasks/result, tasks/cancel, or CreateTaskResult handling in packages/rsc-runtime/src or packages/agent-bundle/src, and docs/*.md do not mention MCP Tasks.

#102 also has a criterion that is currently satisfied only vacuously ("when an MCP-generated command uses the wire … it preserves negotiated progress/task support and the distinct ordinary-request versus task cancellation/result flows") because routes.mcpCommands never uses the wire. If a wire-backed projection ever lands, it inherits this item.

Scope

• Generated MCP servers advertise task support only when the tool and server genuinely implement it (MCP 2025-11-25 Tasks utility); no capability claim without the lifecycle behind it.
• A task-augmented tools/call returns a CreateTaskResult; tasks/get reports status; tasks/result returns the same final CallToolResult the ordinary path would have produced from the same Agent Document; tasks/cancel maps into the renderer AbortSignal.
• The caller's opaque progress token stays valid through the task's terminal state; progress remains optional and never carries partial content.
• Proof at the mcp-in-memory level (real SDK client over InMemoryTransport) plus the single packed journey, per the meta-framework: execution plan and sequencing #107 cost rules (no new build/pack/spawn).
• Docs: docs/entry-conventions.md stdio lifecycle section and packages/agent-bundle/README.md testing story.

Non-goals

• A rich partial-result stream (the projector still buffers shell/replacement internally).
• Any change to the ordinary tools/call contract already pinned by feat(runtime): MCP progress projector and warm-runtime proofs (#96) #175.

Refs: #96 (acceptance remainder), #175, #102, #107.

[ScriptedAlchemy]

Assessment (2026-09-02): deferred — the installed MCP SDK has no task runtime

Audited the pinned spec revision and the installed SDK before touching the generated server. The outcome is the honest-deferral branch, not an implementation: building CreateTaskResult / tasks/get / tasks/result / tasks/cancel today would mean hand-rolling the protocol outside the SDK's typed surface, on a shape the next spec revision removes.

Facts recorded

Item	Finding
Conformance revision	2025-11-25 (docs/mcp-conformance.md, @modelcontextprotocol/conformance@0.1.16)
SDK the generated server uses	@modelcontextprotocol/server@2.0.0 (+ client@2.0.0, shared core@2.0.0); LATEST_PROTOCOL_VERSION = 2025-11-25
SDK task surface	Wire types only. The SDK's own declaration: task methods are "2025-11-25 wire vocabulary with no SDK runtime" — request(), setRequestHandler(), ctx.mcpReq.send() exclude tasks/get, tasks/result, tasks/list, tasks/cancel, notifications/tasks/status. Runtime exports: only RELATED_TASK_META_KEY and a @deprecated isTaskAugmentedRequestParams. No TaskStore, no experimental.tasks (the 1.x experimental API was not carried into v2).
Client behaviour	client.request({ method: 'tasks/get' }) throws 'tasks/get' is not a spec method; task result schemas are not exported publicly.
Spec direction	2026-07-28 moved tasks out of core into the io.modelcontextprotocol/tasks extension (SEP-2663): tasks/result and tasks/list removed, polling via tasks/get, new tasks/update. The v2 codec treats execution.taskSupport / capabilities.tasks as deleted fields on that era.
Upstream tracker	typescript-sdk#2189 Implement SEP-2663: Tasks Extension (open, needs decision, v2). Related v2 gaps: #2598 (custom tasks/get/tasks/cancel handlers unreachable on a 2026-07-28 session), #2637 (Client.callTool() rejects CreateTaskResult).

What landed (#394, merged as 055edf1)

Fail-closed behaviour while deferred, proven at the mcp-in-memory level (real SDK client over InMemoryTransport, no build/pack/spawn):

• Generated servers never advertise tasks, even to a client that negotiated tasks.requests.tools.call.
• A tools/call carrying task: { ttl } is processed as an ordinary request and returns one final CallToolResult with no task handle — what the 2025-11-25 Tasks utility requires of a receiver that declared no task capability.
• Raw tasks/get / tasks/result / tasks/list / tasks/cancel answer JSON-RPC -32601.
• Ordinary progress-token gating and the single final result from feat(runtime): MCP progress projector and warm-runtime proofs (#96) #175 are unchanged.

Sentinels so this cannot go stale silently:

• packages/rsc-runtime/tests/mcp-tasks-deferral.test.ts pins the audited SDK version (2.0.0) and asserts every fact above against the installed packages (exact task-named export set, no experimental namespace, typed client refusing task methods, no tasks advertisement, ordinary fallback, -32601).
• packages/agent-bundle/tests/projection/mcp-in-memory.test.ts carries the same two behavioural proofs on the generated server plus a @ts-expect-error on setRequestHandler('tasks/get', …); verified that removing the directive fails tsc today, so the day the SDK admits task methods pnpm typecheck fails.

Docs: docs/mcp-conformance.md (new dated section with SDK pin, spec facts, upstream links, unblock condition), docs/entry-conventions.md stdio lifecycle shell, packages/rsc-runtime/README.md; changeset for @agent-bundle/runtime.

Unblock condition (precise)

A published @modelcontextprotocol/server / @modelcontextprotocol/client release that routes task operations through its typed surface for the revision the conformance lane records at that time:

1. a server-side task store or registerTool task handler that can return a task handle (CreateTaskResult / resultType: "task"),
2. a typed client path that accepts that handle and polls/retrieves the final result,
3. a tasks (or extensions['io.modelcontextprotocol/tasks']) capability the SDK itself gates.

When that ships, the sentinel test and/or pnpm typecheck fail; the follow-up then maps the render lifecycle (working → completed | failed | cancelled), routes tasks/cancel into the renderer AbortSignal, keeps the non-negotiated fallback, and bounds retained results with the existing budget patterns — the scope this issue already describes. Note #102's wire-backed criterion inherits the same unblock.

Leaving this issue open per the deferral rules.