Fabric data-agent calls can now survive a dropped client connection

Microsoft Fabric data agents now support MCP Tasks, allowing a long-running analytics request to continue without keeping one HTTP connection open until the answer is ready. Microsoft’s current product documentation specifies the task lifecycle and client behavior. Microsoft Learn

What changed

A published Fabric data agent already acts as an MCP server exposing one tool: the agent itself. An authenticated MCP client can submit a question, and Fabric grounds the answer in the OneLake sources that the published agent is permitted to access. The endpoint uses MCP over streamable HTTP rather than accepting arbitrary REST requests. Microsoft Learn

With Tasks, a compatible client receives an identifier when an operation is expected to run for a long time. The client can later call tasks/get until work finishes, retain the identifier across a disconnect or restart, and call tasks/cancel when the result is no longer needed. Microsoft cautions that cancellation is not instantaneous: work that is nearly complete may still finish. Clients without Tasks support continue to wait for the response on the original connection. Microsoft Learn

That distinction matters for data-agent workloads. Microsoft specifically points to questions that scan a large table or execute several queries—exactly the requests most likely to outlast a client, proxy, or network timeout. The task handle separates the lifetime of the analysis from the lifetime of one connection. Microsoft Learn

The implementation boundary

This is not automatic durability for every integration. A client must support the io.modelcontextprotocol/tasks extension, store the returned task identifier, poll responsibly, and decide when cancellation is appropriate. Teams should also treat task IDs as operational state: losing the handle after a process restart removes the client’s practical route back to the result, even if Fabric continues the work. Microsoft Learn

Authentication and governance requirements remain. Every MCP request needs a Fabric bearer token with access to the target workspace and agent; the token may represent a user or service principal. The agent must be published, and users need read access to its configured source. Microsoft also warns that responses sent to an external MCP client may leave Fabric’s compliance boundary or geographic region and then fall under that client’s data-handling terms. Microsoft Learn

For production teams, the upgrade checklist is therefore concrete: confirm the client implements Tasks, persist task handles, bound polling, test restart recovery and delayed cancellation, and review where the chosen MCP client processes returned data. Tasks reduce timeout failure; they do not remove identity, lifecycle, or compliance work.