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.