Already 9 months old when the scout caught it.
MCP Tasks
What it is
Tasks is an MCP protocol extension that lets any tool call return a durable handle instead of blocking until the work finishes — a "call-now, fetch-later" pattern. Instead of holding a connection open for a slow operation, the server responds immediately with a task ID; the client polls with tasks/get, watches the task move through statuses (working → input_required → completed/failed/cancelled), and retrieves the result once it's ready — even across a disconnect and reconnect.
Why it's emerging now
MCP servers behind ordinary HTTP infrastructure struggle with slow operations — deep research queries, multi-step agent workflows — because blocking ties up a connection, and many transports and load balancers time out long before that work finishes. Tasks first appeared as an experimental primitive in the 2025-11-25 spec, then was promoted to a formal extension in the 2026-07-28 release candidate as part of MCP's broader shift from a stateful, bidirectional protocol to a stateless request/response one — the same shift that produced MRTR, already on your ledger. That shift lets long-running MCP work run on the same ordinary, horizontally-scaled HTTP infrastructure used for everything else, instead of needing a persistent connection or a session store.
How it relates to what you know
It's a sibling to Multi Round-Trip Requests (MRTR): both let MCP avoid holding a live connection open under the new stateless core, but for different triggers. MRTR handles server-initiated mid-operation requests (elicitation, sampling) that need more input from the client; Tasks handles client-initiated calls that simply take too long to answer synchronously. Both are pieces of the same stateless redesign as MCP Apps, already on your ledger.