A normal MCP tool call is a request and a response: the model calls a tool, the server does some work, and the result comes back before the connection times out. That works fine for a lookup. It falls apart for anything that takes real time — crawling a site, running a large export, waiting on a batch job somewhere else. MCP Tasks, one of the extensions introduced alongside MCP’s 2026-07-28 spec update, gives servers a standard way to handle that instead of everyone inventing their own workaround.
The problem it’s solving
Before Tasks, a server with slow work had two bad options. Hold the connection open and hope the client’s timeout is generous enough — which breaks the moment the job takes longer than expected, and breaks by default on infrastructure that isn’t built to hold connections open at all. Or build a private polling scheme: return an ID, expose a made-up second tool to check on it, hope the model calls that tool at reasonable intervals instead of spamming it or forgetting about it entirely. Every server that needed this rolled its own version, and every client had to learn each one.
MCP Tasks replaces the private version with a shared one: a standard way to start a task, check its status, and fetch the result once it’s done, defined by the protocol instead of improvised per server.
How it changes the flow
Instead of a single request that blocks until the work is finished, a task-backed tool call becomes three steps: kick off the work and get back a task reference, poll that reference for status, then retrieve the result once the task reports done. The model — or the client managing the conversation on its behalf — doesn’t have to sit on an open connection waiting, and the server doesn’t have to guess how long a client is willing to wait before it gives up.
That pairs naturally with the other headline change in the same update: MCP moving to a stateless request/response core. A server that doesn’t have to hold a long-lived connection open for a slow job can run as a plain serverless function instead of a process that has to stay alive for the duration of the work. Tasks is what makes “slow work” compatible with that stateless model, rather than the one thing that forces a server back into holding a session open.
If you build a server
Tasks is worth reaching for when a tool genuinely takes longer than a normal request timeout tolerates — crawling, large exports, anything that calls out to a slow third-party job. It’s not a default to wrap every tool in. Most tools finish fast enough that a plain request/response call is simpler for you to implement and simpler for a client to handle, and adding a task wrapper to something that returns in under a second just adds round trips for no benefit.
If you’re generating a server from an existing API with a tool like gate’s MCP server builder, an OpenAPI spec doesn’t carry task semantics on its own — a conversion tool can map endpoints to tools, but deciding which of those calls are slow enough to deserve the task pattern is a judgment call on top of the generated surface, the same way we noted for sampling and MCP Apps. See turning an API into an MCP server for the more common path most tools still take.
If you use MCP servers
Rollout here is the same gradual, dual-version story as the rest of the July update: some servers will adopt Tasks for their slow operations, most tools won’t need it at all, and clients will keep supporting plain request/response calls as the default for a long time yet. Day to day, the practical difference is that a slow operation on a Tasks-aware server should behave more predictably — a status you can check, a result you can fetch — instead of a connection that either hangs or silently times out with no way to know if the work happened anyway.
That last point is worth sitting with for a moment: a task that timed out on the client side isn’t necessarily a task that failed on the server side. Before Tasks standardized status checking, there was often no reliable way to tell the difference, which is its own version of the retry problem we covered in MCP tool idempotency — a client that can’t confirm whether a call finished is a client that might retry it, and a task that isn’t safe to run twice turns that uncertainty into a duplicate action.
The bottom line
MCP Tasks gives servers a standard start-check-fetch pattern for work that takes too long for a normal request, instead of every server inventing its own polling scheme. It pairs with MCP’s move to a stateless core, it’s only worth using for genuinely slow operations, and it doesn’t change what the underlying tool is authorized to do. See gate’s MCP server directory for what’s actually shipping today.