Azure OpenAI Responses API returns model_error during deferred MCP tool search

The supported workaround is to keep deferred loading disabled and send the MCP tool surface directly while Microsoft investigates the failed deferred-search orchestration.

Unrecognized recipient: api_tool indicates that model-generated content targeted a recipient the model-serving/tool-orchestration layer could not route. It is not a documented MCP protocol error, and the available events do not establish that the remote MCP server returned an error.

What the event sequence establishes

For hosted tool search, the expected sequence is:

1. tool_search_call
2. tool_search_output, containing the tools Azure loaded
3. The resulting MCP or function call

Azure documents execution: "server" and a null call_id as hosted search. Client-executed search instead requires the application to return tool_search_output with the same call_id as the preceding search call.^1^

Your stream ends after tool_search_call: in_progress, before tool_search_output or an MCP-call event. Therefore:

• The deferred search did not complete.
• There is no response-level evidence that an MCP tool was invoked.
• There is no MCP error payload showing that the server rejected discovery or execution.
• api_tool appears to be an internal routing recipient, not a tool name your application should execute or return.

The authoritative way to determine whether Azure contacted the server is to correlate the failure timestamp with the MCP server’s access logs. If no matching tool-list/discovery request exists, the failure occurred before MCP contact. If a request exists, preserve its status, response body, latency, and correlation headers for Support.

HTTP 200 does not mean the streamed operation completed successfully. Responses streaming can begin successfully and later emit an unrecoverable error event; clients must stop or restart the stream when that occurs.^2^ The Java SDK surfacing that event as SseException is consequently consistent with a mid-stream failure.

Applicability checks

The reported platform combination meets the documented high-level prerequisites:

• Tool search requires gpt-5.4 or later.
• gpt-6-luna is listed as a Responses API model.
• East US 2 is listed as a Responses API region.
• previous_response_id is a supported continuation mechanism.^1^ ^2^

No documented requirement says deferred tools cannot be searched again across a valid previous_response_id chain. The published known-issues list also does not identify this specific deferred-MCP continuation failure.^2^

Because nondeferred loading works with the same MCP server, repeating generic MCP reachability checks is unlikely to isolate this particular failure.

Recommended mitigation and isolation

1. Production workaround: continue declaring the MCP server without defer_loading: true. This bypasses the failing discovery stage while retaining MCP execution.
2. Retry the whole failed turn, not the existing SSE stream. Once the stream emits the terminal error, discard its partial result and create a new response from the last successfully completed response ID. Do not use the failed response as the next previous_response_id.
3. Run one diagnostic with parallel_tool_calls: false. This is not a documented fix, but it cleanly determines whether concurrent routing contributes to the failure. Keep deferred loading enabled for this diagnostic so only one variable changes.
4. Capture raw SSE before SDK translation. Preserve, in order:
   • response.created
   • every response.output_item.* event
   • the complete tool_search_call
   • the terminal error event
   • response headers
   • exact request JSON with secrets removed
5. Compare continuation paths:
   • same prompt as a new conversation;
   • same prompt with previous_response_id;
   • continuation with deferred loading disabled.
   Your existing result already distinguishes the last variant; the first two identify whether the defect requires continuation state.

Escalation package

This pattern warrants an Azure support request because it reproduces in a supported model/region and stops inside server-side search orchestration. Include:

• UTC timestamp, region, resource and deployment names, and deployment model version;
• Azure request ID, APIM request ID, response ID, previous response ID, and application attempt ID;
• sanitized request body and complete raw SSE;
• Java SDK version and Azure v1 endpoint/API details;
• MCP server access logs covering the same timestamp;
• a minimal two-turn reproduction;
• the matrix for deferred on/off, previous_response_id on/off, streaming on/off, and parallel calls on/off;
• confirmation that direct, nondeferred MCP loading succeeds.

Azure Support accepts reproduction steps and compressed log attachments under Azure portal → Help + support → Create a support request.^3^

Avoid publishing the identifiers from the failing production request further; provide them only in the private support case.

References

1. Use tool search with the Azure OpenAI Responses API
2. Use the Azure OpenAI Responses API - Microsoft Foundry
3. Create an Azure support request