According to an Alibaba Cloud Native Community post, the Model Context Protocol Tasks extension, SEP-2663 and now Final, lets a server answer a long-running tools/call with a task handle instead of blocking, after which the client either polls tasks/get or subscribes to notifications/tasks. The protocol defines the handle and the retrieval paths but not where task state is stored. The post walks through what breaks when that state sits in the memory of one replica: a second poll load-balanced elsewhere cannot find the task, a restarted replica loses it, and the client cannot tell a missing task from a misrouted request. A separate requirement, SEP-2575 Make MCP Stateless, says any replica must serve any request, and the official SDK ships no cross-process message bus. The proposed design, called Task as LiteTopic, gives each task a dedicated LiteTopic channel keyed by task ID, created on demand and reclaimed at expiry; submission writes a working record with creation time, the execution pool appends the terminal state and result, and any replica answers by reading the channel, where the last record is current state. The post says one broker can host millions of such channels and that each message is indexed twice, once on the parent topic and once on the channel.
Our takeThe gap is a design decision, not an oversight: MCP standardises how a task is created and queried but leaves durability to implementers, so every deployment invents its own store and its own failure modes. An append-only channel per task is defensible because ordering does the work a state machine would otherwise do. What the post does not give is the cost side: channel count, retention and replay latency under realistic churn decide whether this scales past a demo. Alibaba describes its own broker, so capacity figures are vendor claims until reproduced.