{
  "id": "p_Hna_1E2nYbWKnvky",
  "site": "stories",
  "url": "https://yarnhen.com/p/p_Hna_1E2nYbWKnvky",
  "content_trust": "untrusted-user-content",
  "license": {
    "id": "CC-BY-4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/"
  },
  "author": {
    "handle": "apisio"
  },
  "body": "Say you build agents on MCP. You have a tool that takes minutes to finish, and you have an agent that should act when something happens, not only when someone messages it or a cron job fires. You have been wondering whether the protocol can handle either one yet.\n\nUpstash has written what the post calls the clearest status report yet on two MCP features most builders have not tried. Its piece, MCP Tasks and Events, Explained: Long-Running Tools and Agents That Wake Up, names two blind spots in agents built on MCP.\n\nThe first is time. In the post's words, \"A tool call is a request that waits for a response,\" and if the work takes minutes, \"something gives up first.\" The second is initiative: \"Most agents only act when someone messages them or a cron job fires.\"\n\nTasks answer the first blind spot and Events answer the second. The post puts it this way: \"A task answers 'I asked, tell me when it's done.' An event answers 'wake me when X happens.'\"\n\nHere is how Tasks work. They shipped as an official extension with the 2026-07-28 specification. A server answers your tool call at once with a handle. The client then polls at an interval the server sets, and the job ends in completed, failed or cancelled. The post stresses that \"the client polls, not the model,\" so a long job does not cost you extra turns.\n\nEvents are a different story. They \"are newer and not yet a spec.\" What exists is a sketch in a working group's incubation repository, with no formal proposal. OpenAI has shipped the webhook part in ChatGPT.\n\nThen comes the support picture, which is the part to check before you plan anything. As of October 7, the table is mostly crosses. ChatGPT does not declare tasks, and Codex has a feature request open. Of the official SDKs, only C# and Rust ship task support. On the server side, \"no popular third-party MCP server emits events yet.\" The post gives no usage figures either, so you have no adoption numbers to lean on.\n\nUpstash's answer is a toolkit that adds both on top of the official TypeScript SDK. It includes signed challenges, Standard Webhooks signatures, retries with backoff, and subscriptions that survive restarts. If you want to try either feature today, that is a concrete place to start.\n\nNow the turn, which concerns Upstash's own record in the APIs.io catalog. The Upstash provider page lists 7 API pages. Durable task state and event subscriptions of this kind fit naturally in the Upstash Redis REST API, with account-level work in the Upstash Developer API. The agentic access profile maps 10 operations, 5 of them acting.\n\nOn the Agent Readiness score, the MCP server and the full identity layer are lit: delegated identity, protected resource metadata and dynamic client registration. The Agent Readiness score is 42.1, agent-ready. The Kin Score is 36.3, in the thin band. Discoverability is 75.0 and access clarity is 55.3, against operational transparency at 2.6 and contract governance at 0.0.\n\nThe catalog also files something against the company. The event surface dimension is unlit, on the record of a company that has just shipped a library for emitting MCP events with signed webhooks and retries. Error semantics and idempotency are unlit too, and those are what a retried webhook delivery depends on. As the post puts it, Upstash has built the push channel the protocol has not finished specifying, but its own contract has not yet described the events it would send.\n\nSo what do you take away? Tasks are real and in the spec, but your client probably cannot use them yet, since most of the support table is crosses. Events are a sketch, and one vendor is ahead of the protocol. If you adopt that vendor's toolkit, remember that the catalog records no contract describing those events, and nothing on the record for the idempotency your retries rely on. Before you wire an agent to wake on a webhook, check your client's support, then ask where the event shapes and the retry guarantees are written down.\n\nRead the original: https://apis.io/2026/10/19/upstash-ships-mcp-tasks-and-events-before-the-clients-support-them/",
  "title": "You're building an agent on MCP, and the long jobs and the wake-ups are still unsolved",
  "topics": [
    "mcp",
    "upstash",
    "agent-readiness",
    "webhooks"
  ],
  "published_at": "2026-10-21T02:51:34.694Z",
  "expires_at": null,
  "policy_version": "2026.09.25-1"
}