Forum Discussion

Carlo-Data's avatar
Carlo-Data
Copper Contributor
Sep 02, 2026

Agent with Fabric data agent tool times out at 100s even in background mode

A Foundry agent with a Fabric data agent attached cancels any tool call that takes longer than 100 seconds, even with background mode enabled on a model that supports it. The documentation presents background mode as the supported path for MCP tool calls that exceed the synchronous timeout, but it does not lift the limit here.

Setup

  • Foundry project on Microsoft.CognitiveServices, West Europe
  • Agent kind prompt, model gpt-5.6-luna (2026-07-09)
  • metadata."microsoft.background-mode.enabled": "true"
  • Requests to {project_endpoint}/openai/v1/responses with "background": true and an agent_reference
  • Tested with both the fabric_iq_preview tool and the generic mcp tool, same server_url and same project_connection_id (authType: UserEntraToken)

Behaviour

Background mode is genuinely active: the response returns status: queued immediately and stays in_progress well past 100 seconds, so the model does support it. But the MCP tool call inside the run is still cancelled at exactly 100 seconds:

{ "code": "tool_user_error", "message": "TaskCanceledException encountered while invoking tool DataAgent_<name>: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.. The remote MCP server did not complete the request within the configured timeout." }

Same failure both ways — fabric_iq_preview failed at 115s, generic mcp at 108s. The response output shows a single mcp_call with status=failed.

Why this looks like a Foundry-side gap

The Fabric data agent MCP server advertises task support on initialize:

"capabilities": { "tools": { "listChanged": false }, "tasks": { "list": {}, "cancel": {}, "requests": { "tools": { "call": {} } } } }

and per tool in tools/list:

"execution": { "taskSupport": "optional" }

Calling that same server directly as a task, rather than through Foundry, completes the exact query Foundry cancels — in 81 to 173 seconds depending on the run. So the data agent can answer these questions; only the call made by Foundry is constrained.

One detail that may explain it: the server advertises tasks as a top-level capability and accepts a task via a task field in the request params — an earlier form of the extension, rather than the current capabilities.extensions["io.modelcontextprotocol/tasks"] negotiation. A client following the current draft would not find the capability where it expects it and would fall back to a blocking call, which matches what we see.

Questions

  1. Is background mode expected to lift the 100-second tool-call timeout for a Fabric data agent today, or is that combination not yet supported?
  2. Does Foundry's MCP client negotiate tasks with a server advertising them in this older form? If not, is alignment planned?
  3. Is there any setting, api-version, or tool property that makes Foundry request a task instead of blocking? Nothing in the agent definition or the portal changed the behaviour for us.

2 Replies

  • Jamony's avatar
    Jamony
    MCT
    Sep 04, 2026

    Your test shows the Fabric data-agent call is still failing at the MCP client’s 100-second HTTP timeout. Polling the background response cannot extend a tool request that the platform has cancelled. Microsoft’s Foundry guidance says long-running MCP work requires a background-mode-capable model and an MCP server that supports tasks; it also documents a 100-second limit for non-streaming MCP calls. Confirm the model, API version, agent definition, and Fabric connection are using the current task-capable path. Capture the response ID, tool-call output, region, server capability response, and timeout timing for a Microsoft support request. I cannot identify a setting that forces Foundry to negotiate the older task capability format you observed. Until that path is supported, reduce the Fabric operation so each call returns within 100 seconds, split the query into stages, or run the longer task directly against the MCP server and pass its completed result back to the agen

    • Carlo-Data's avatar
      Carlo-Data
      Copper Contributor
      Sep 04, 2026

      According to the current Microsoft Foundry documentation, Fabric Data Agent MCP endpoints are specifically documented as supporting long-running operations through Background mode. The docs also state that Background mode allows MCP tool calls to exceed the standard 100-second non-streaming timeout.

       

      In the screenshot below you can see that I am using:

      • a background-capable model (gpt-5.6-luna)
      • the Fabric IQ connection to the Fabric Data Agent
      • Background mode enabled
      • the run actually starts as a background task

       

      However, the Fabric Data Agent tool call still fails with:

      HttpClient.Timeout of 100 seconds elapsing

       

      So the background response itself is working, but the internal Fabric Data Agent MCP call is still being cancelled at the synchronous 100-second limit.

       

      This is the part I am trying to understand: is this currently a limitation/bug in the Foundry ↔ Fabric Data Agent integration, or is there an additional setting required for the Fabric IQ tool call to actually run as a long-running MCP task?

       

      Microsoft’s documentation says that, among Fabric IQ item types, the Data Agent MCP endpoint is the one that supports long-running operations through Background mode, and that in the portal the expected flow is to enable Background mode, add the Data Agent through Fabric IQ, and send the query.

       

      Doc capture:

      https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/model-context-protocol?view=foundry&pivots=python#long-running-operations-preview

       

      Failed test capture: