SEP-2557: Tasks v2 — stateless/sessionless adaptation (parallel implementation) #296

Context

SEP-2557 proposes major simplifications to MCP Tasks for the June spec release. Status: Draft. We want to be first with a reference implementation — coexisting alongside current tasks v1 in main.

Related SEPs:

• SEP-2322: Multi Round-Trip Requests
• SEP-2260: Server requests must be associated with client requests
• SEP-2567: Sessionless MCP via Explicit State Handles

Key Changes from v1

Implementation Plan

Structure: v1 and v2 coexist

```
server/
├── tasks_experimental.go ← v1 (current, spec 2025-11-25)
├── tasks_v2.go ← v2 (SEP-2557)
├── task_store.go ← shared store (both versions)
├── task_store_v2.go ← v2-specific store changes (if needed)
├── task_session.go ← v1 TaskContext
├── task_session_v2.go ← v2 TaskContext (inputRequests model)
└── task_queue.go ← v1 message queue (v2 doesn't need it)

client/
├── tasks.go ← v1 helpers
└── tasks_v2.go ← v2 helpers (auto-detect CreateTaskResult)

conformance/
├── tasks/scenarios.test.ts ← v1 conformance (9 scenarios)
└── tasks-v2/scenarios.test.ts ← v2 conformance (new scenarios)
```

Registration

```go
// v1 (current)
server.RegisterTasks(server.TasksConfig{Server: srv})

// v2 (SEP-2557)
server.RegisterTasksV2(server.TasksV2Config{Server: srv})
```

What changes in v2

1. No `task` param — middleware returns CreateTaskResult based on tool's `execution` field
2. `tasks/get` returns everything — status, result (when terminal), inputRequests (when input_required)
3. No `tasks/result` — removed entirely
4. No `tasks/list` — removed entirely
5. No capabilities — tasks are core, not negotiated
6. `tasks/cancel` required — server MUST support it
7. TTL in seconds — not milliseconds
8. `inputRequests`/`inputResponses` in `tasks/get` — MRTR model for elicitation

What's shared between v1 and v2

• `TaskStore` interface (with minor additions for v2 result inlining)
• `InMemoryTaskStore` (TTL, session isolation, terminal guards)
• `TaskContext` core concept (but v2 version uses inputRequests model)
• `core.TaskInfo`, `core.TaskStatus`, `core.CreateTaskResult`

Conformance

Both v1 and v2 conformance suites in `conformance/`:

• `conformance/tasks/` — v1 (current 9 scenarios)
• `conformance/tasks-v2/` — v2 (new scenarios matching SEP-2557)

```bash
make testconf-tasks # v1
make testconf-tasks-v2 # v2
```

Phases

1. Core types + v2 `tasks/get` handler (status + inlined result)
2. Server-directed task creation (no `task` param)
3. `inputRequests`/`inputResponses` in `tasks/get` (MRTR model)
4. v2 conformance suite
5. Example server with both v1 and v2
6. Client auto-detection (`callTool` handles CreateTaskResult transparently)

Timeline

SEP-2557 is Draft — implement now to be first, adapt as spec evolves.