Foundry Agent Service: MCP tool result with isError ends the whole response (tool_user_error) on the new Responses API

Summary

In the new Foundry Agent Service (Responses API with agent_reference), a remote MCP tool call whose result has isError: true ends the entire response with tool_user_error. The model never sees the tool error, so it cannot correct its call or continue with other steps, as the MCP specification intends for tool execution errors.

The classic agents API (threads/runs) handles the same tool result correctly: the error goes back to the model and the run completes.

Steps to reproduce

1. Use any remote MCP server with a tool that returns a tool execution error, for example {"content":[{"type":"text","text":"Unknown connector 'DOES_NOT_EXIST'"}],"isError":true}.
2. Create a prompt agent with that MCP tool (require_approval: never) and the instruction to carry out every step, also when a step fails.
3. Send: "Step 1: describe connector DOES_NOT_EXIST. Step 2: list the connectors. Then report the result of each step."

Expected (MCP spec, tools, error handling: tool execution errors are reported with isError: true so the model can react): the model receives the error for step 1, runs step 2 and answers.

Actual on the new API, the response ends at the first error:

• synchronous: HTTP 400 without a response id
• stream: true: response.failed
• background: true: status failed, error.code = tool_user_error, no answer

Same request on both APIs (Sweden Central, October 2026)

• gpt-4.1: classic API completed (error returned to the model, step 2 ran); new API failed with tool_user_error.
• gpt-5.6-luna: new API failed with tool_user_error; does not run on the classic API.
• claude-sonnet-5: new API failed with tool_user_error; does not run on the classic API.
• claude-opus-5-5: new API failed with tool_user_error; does not run on the classic API.

The behaviour follows the API, not the model.

Impact

Agents that read business data through MCP regularly make a recoverable tool call error (a wrong field, an unknown record, a rate limit). On the new API each one ends the agent's whole task. Classic agents retire on 31 March 2027 and do not run newer models, so moving back is not an option.

Workaround

Run with background: true, store: true. When a response fails with tool_user_error, start a new response with previous_response_id set to the failed one and a short note quoting the tool error. The agent continues with its earlier tool results intact. This works, but it is undocumented

Questions

1. Can an MCP tool result with isError: true be returned to the model as the tool output, as the classic API does, instead of ending the response? If ending is sometimes wanted, could it be a setting on the MCP tool?
2. Is continuing from a failed response with previous_response_id supported?
3. Could the tool's own error (isError) be kept apart from transport or authentication failures in the response, so clients can tell them apart?