What happened
Upstash published @upstash/mcp-toolkit/tasks, an addition to its MCP toolkit for implementing the MCP Tasks extension. The extension lets an MCP server answer a slow tool request immediately with a task handle rather than waiting for the work to finish. A compatible client can then poll for completion, retrieve the normal tool result, or cancel the task. Upstash says Claude Code supports MCP Tasks and MCP Elicitations; David Soria Parra, a co-creator of MCP at Anthropic, announced Claude Code support at AGNTCon + MCPCon North America in San Jose on October 22, 2026.
The toolkit is aimed at a mismatch between slow agent tools and serverless execution. A serverless function cannot keep working after it has returned a response, is subject to a timeout, and does not share process memory with a later invocation. In Upstash’s serverless configuration, task state is stored in Upstash Redis. QStash dispatches a task to a fresh invocation of an execution endpoint and retries it if it fails. Where one task needs more than one function invocation, the post points to a WorkflowDispatcher backed by Upstash Workflow, with each step in its own invocation.
The protocol behavior is specific. With a client that advertises the Tasks extension, such as Claude Code, the toolkit returns a native task and the client polls it itself. The example task response includes a task ID, a working status, a 24-hour TTL, and a two-second suggested polling interval. With clients that do not advertise the extension, the same server instead returns a normal tool result containing the task ID, plus task_status and task_cancel operations. That makes the toolkit a compatibility layer rather than a requirement that every MCP client immediately implement the extension.
The post also describes Elicitations, a mechanism through which an MCP tool can present a small form to the user. After the user responds, Claude Code repeats the tool call with the response in inputResponses; the server does not need to block while waiting. A task can use this mechanism to ask for approval partway through a flow. MCP Tasks is a public beta in Claude Code CLI from version 2.1.304 and works in interactive terminal sessions, Agent SDK sessions, and GitHub Actions runs. It does not make calls from subagents, one-shot claude -p runs, the VS Code extension, or the desktop app task-aware. Further, questions inside a task reach a user only in an interactive terminal session. Claude Code can separately move a conventional MCP call to the background after two minutes, but Upstash notes that this still leaves the server holding the request open and therefore does not solve function time limits.
What the archive adds
This is a new implementation detail on a known Claude Code and MCP Tasks story, rather than a separate protocol announcement. Earlier coverage of Claude Code’s MCP Tasks and Elicitations established the client capabilities; the Upstash release shows one way an MCP server can persist and execute those tasks in a serverless environment.
Trend signal
This supports Agent protocols become the interoperability layer. The same tool can expose native asynchronous behavior to a client that declares MCP Tasks while retaining a usable fallback for clients that do not. That separation of server capability from a particular model client is the important signal.
Why now
The timing follows Claude Code’s public-beta support for MCP Tasks from CLI version 2.1.304 and the October 22 conference announcement. Upstash is packaging the server-side persistence, dispatch, and retry pieces needed when task-aware clients meet the execution limits of serverless functions.
Why it matters
For teams building agent tools, a long-running operation no longer has to be modeled as a fragile synchronous tool call. A report generator, publishing workflow, or other slow operation can return a handle, survive a request boundary, and later yield a normal MCP result. The practical benefit is not merely background execution: it is an explicit lifecycle with status, cancellation, retries, and, where the client is interactive, a controlled point for user approval.
The limits matter just as much. Builders cannot assume that declaring a task makes every Claude Code surface asynchronous, or that an elicitation can obtain human input from a CI run. A production design needs a fallback path for non-task-aware clients and a separate policy for unattended execution.
What happens next
- More MCP clients will advertise Tasks support beyond the current Claude Code surfaces. (6 months, 65%). Watch for: client capability declarations and documented support in other Claude products.
- Serverless MCP deployments will package durable stores and dispatchers as standard task infrastructure. (6 months, 70%). Watch for: additional toolkit integrations using persistent task state and per-task execution endpoints.
Limits and uncertainty
The source is an Upstash product post and demonstrates its own toolkit; it does not provide independent reliability, latency, cost, or scale measurements. It does not establish that Redis, QStash, or Workflow are necessary for every MCP Tasks deployment: its in-memory example works until a process restart or a request lands on a different instance. The source also says Anthropic plans broader product support, but supplies no date or scope for that expansion. Public beta status means the Claude Code behavior and supported surfaces may change.
Skill to build now
Take one MCP tool that can exceed an ordinary request timeout and define its task contract this week: immediate task creation, status retrieval, cancellation, expiration, and the final result. Then test it in both modes described by Upstash: a client that declares the Tasks extension and a client that receives a conventional result with explicit status and cancel operations. If human approval is required, make the unattended path safe without assuming an interactive elicitation form exists.
Reader takeaway
MCP Tasks turns a slow tool call into a durable, inspectable unit of work, but only when both client behavior and server-side execution support it. Upstash’s release supplies the serverless plumbing; Claude Code’s current public beta supplies a task-aware client on selected surfaces.
Open question
Will task-aware MCP behavior arrive soon in subagents, one-shot runs, the VS Code extension, and desktop clients, or will builders need to maintain separate interaction models for those environments?