Foundry Hosting drops the standard Responses approval_request_id relationship when converting a provider MCP call into an outbound response. Clients consequently cannot identify which approval authorized that call.
Observed behavior
Reproduced with agent-framework-core 1.17.0, agent-framework-foundry-hosting 1.0.0b260910 and azure-ai-agentserver-responses 2.2.0b1. The same emission paths were also inspected at commit 0ad2e44.
- The provider MCP call carries
approval_request_id in the original item retained by Content.raw_representation.
_OutputItemTracker._open_mcp_call passes server label, tool name and item ID to the response builder, but omits the approval link.- Hosting generates a new outbound ID for
mcp_approval_request and stores that ID with the original approval content for incoming decisions. Copying the provider's original approval ID unchanged would therefore be insufficient when the outbound approval has a different ID.
For example: a provider issues approval A, Hosting exposes approval B, and the client approves B. The provider must receive the decision for A. When its subsequent mcp_call refers to A, the outbound call must refer to the corresponding approval B that the client received. Currently that outbound relationship is lost.
Expected behavior
Preserve the explicit approval relationship through incremental events, terminal snapshots, stored history and continuation. Both incoming decisions and outgoing call references must use the appropriate identities for their side of the transport boundary. Do not reconstruct identity from matching names, arguments or output text.
The relationship is defined by the OpenAI Responses MCP contract.
Related SDK change
Azure/azure-sdk-for-python#49037 adds optional approval_request_id support to the MCP builder and preserves it in added/done/terminal output. Hosting still needs to supply the correct outbound approval identity.
Implementation and validation considerations
Confirm whether Hosting should preserve provider IDs or persist an explicit source-to-outbound mapping, including storage scope, collision handling and replay rules. Follow the function-calling loop specification for approval-resume and history changes.
Cover multiple same-name/same-argument approvals, generated outbound IDs, approve/deny, matching call references, restart/replay, and streaming/non-streaming output. This issue concerns existing standard MCP relationships; it does not propose adding a local-function approval field to the protocol.
Foundry Hosting drops the standard Responses
approval_request_idrelationship when converting a provider MCP call into an outbound response. Clients consequently cannot identify which approval authorized that call.Observed behavior
Reproduced with
agent-framework-core 1.17.0,agent-framework-foundry-hosting 1.0.0b260910andazure-ai-agentserver-responses 2.2.0b1. The same emission paths were also inspected at commit0ad2e44.approval_request_idin the original item retained byContent.raw_representation._OutputItemTracker._open_mcp_callpasses server label, tool name and item ID to the response builder, but omits the approval link.mcp_approval_requestand stores that ID with the original approval content for incoming decisions. Copying the provider's original approval ID unchanged would therefore be insufficient when the outbound approval has a different ID.For example: a provider issues approval
A, Hosting exposes approvalB, and the client approvesB. The provider must receive the decision forA. When its subsequentmcp_callrefers toA, the outbound call must refer to the corresponding approvalBthat the client received. Currently that outbound relationship is lost.Expected behavior
Preserve the explicit approval relationship through incremental events, terminal snapshots, stored history and continuation. Both incoming decisions and outgoing call references must use the appropriate identities for their side of the transport boundary. Do not reconstruct identity from matching names, arguments or output text.
The relationship is defined by the OpenAI Responses MCP contract.
Related SDK change
Azure/azure-sdk-for-python#49037 adds optional
approval_request_idsupport to the MCP builder and preserves it in added/done/terminal output. Hosting still needs to supply the correct outbound approval identity.Implementation and validation considerations
Confirm whether Hosting should preserve provider IDs or persist an explicit source-to-outbound mapping, including storage scope, collision handling and replay rules. Follow the function-calling loop specification for approval-resume and history changes.
Cover multiple same-name/same-argument approvals, generated outbound IDs, approve/deny, matching call references, restart/replay, and streaming/non-streaming output. This issue concerns existing standard MCP relationships; it does not propose adding a local-function approval field to the protocol.