When should an MCP server run a tool as a task instead of answering synchronously?

## Framing the decision This is a design judgment, not a rule in the specification. The specification gives you a mechanism — the `io.modelcontextprotocol/tasks` extension, `CreateTaskResult`, `tasks/get`, `tasks/update`, `tasks/cancel` — and leaves the choice of when to use it to the server author. A strong answer therefore names the forces rather than reciting the API. ## The forces pushing toward a task **Duration versus connection lifetime.** The blunt version: can this finish before something between the client and the server gives up? Load balancers, proxies and mobile networks all impose their own idle and total-duration limits, and none of them are yours. Anything routinely measured in minutes should not be riding a held-open response. **Loss of a stream is loss of the work.** Revision 2026-07-28 removed SSE resumability outright — no event ids, no `Last-Event-ID`. If the stream carrying a synchronous call breaks, the in-flight request is lost and the client must re-issue it as a new request with a new JSON-RPC id. If the operation is expensive, non-idempotent, or has already had side effects, that is a genuinely bad outcome. A task decouples the work's lifetime from any connection's. **Human latency.** If the operation can pause for an approval, a credential, or a choice, its duration is set by a person, not a machine. A task's `input_required` status plus `tasks/update` is built for exactly this; a synchronous call gated on a human is a request held open for however long lunch takes. **Scale-out.** With protocol-level sessions removed in 2026-07-28, an explicit server-minted handle is the sanctioned way to carry state across requests. A `taskId` lets the create, the polls and the cancel each land on different nodes, which is what a horizontally-scaled remote server needs. ## The forces pushing back **Tasks are real infrastructure.** A task must survive the process that created it, or the design is a lie — so its state goes in shared storage. That brings serialization, migration of that stored shape, and failure handling when the storage is down. **Retention becomes a policy question.** How long does a `completed` task's result stay fetchable? Long enough that a client which slept and reconnected can still collect it; short enough to bound storage. There is no protocol answer; you have to pick, document and enforce one. **Abandoned tasks accumulate.** A client can start work and vanish, or park a task in `input_required` and never update it. The server needs its own timeouts, and clients should `tasks/cancel` what they abandon — but you cannot rely on that. **Support is not guaranteed.** Tasks are an extension. A client that never declared `io.modelcontextprotocol/tasks` must be answered synchronously or refused, so the synchronous path exists regardless. If your operation is only viable as a task, you have a tool that some clients simply cannot use, and that is a product decision, not a technical one. ## The often-better third option Before reaching for tasks, ask whether the operation can be made small. Splitting a long job into a start call that returns a server-minted handle as an ordinary tool result, plus separate progress and fetch tools taking that handle as a plain argument, gives you durability with no extension dependency at all — it is just tools and arguments. That pattern works with every client, at the cost of designing the handle, its lifetime and its authorization yourself. Tasks are the standardized version of the same idea; hand-rolling is the portable version. Choosing between them is exactly the kind of tradeoff this question is asked to surface. ## Security note on handles Whichever route you take, possession of a handle is not authentication. MCP 2026-07-28 replaced the old "session hijacking" discussion with "state handle hijacking" and is explicit that holding a handle must not be treated as proof of identity. A `taskId` that leaks must not let a different caller read someone else's results — authorize every `tasks/get`, `tasks/update` and `tasks/cancel` against the credential presented on that request, exactly as you would any other call. ## A workable heuristic - Sub-second to a few seconds, idempotent, no side effects: synchronous, always. - Tens of seconds: synchronous is usually still fine; measure your worst-case network path before assuming so. - Minutes, or any human gate, or side effects you cannot afford to repeat: task. - Hours: task, plus an explicit retention and cleanup policy, plus a client story for what happens when nobody comes back. ## Interview framing Lead with the criterion — can the work finish inside one request's realistic lifetime, and is repeating it acceptable if it cannot — then name the costs a task imposes (durable state, retention, abandoned-task cleanup, extension dependency), then mention the hand-rolled handle alternative and the rule that a handle is not authentication. That is the shape of an answer that sounds like someone who has operated one of these rather than read the schema.