Repository navigation
Python: [Bug]: MCP Tool Calls + Reasoning Not Emitted as AG-UI Events (Foundry) #4213
Description
Description
On Foundry (Responses API) streams, mcp_server_tool_call, mcp_server_tool_result, and text_reasoning content items are received by the server but produce no AG-UI SSE events because they fall through unhandled in _emit_content.
Impact: frontends consuming AG-UI events cannot display MCP tool execution state (tool call start/result) and cannot reflect reasoning/progress during text_reasoning.
Scope
Foundry agents only (Azure AI Foundry / OpenAI Responses API MCP tool items).
Standard function_call / function_result mapping is unaffected.
Where It Happens
agent_framework_ag_ui/_run.py::run_agent_stream dispatches each streamed content item through _emit_content(...) and yields whatever events it returns. If _emit_content returns [] for a given content type, nothing is emitted to the SSE stream.
# Emit events for each content item
for content in update.contents:
content_type = getattr(content, "type", None)
logger.debug(f"Processing content type={content_type}, message_id={flow.message_id}")
for event in _emit_content(
content,
flow,
predictive_handler,
skip_text,
config.require_confirmation,
):
yield event
Evidence / Symptoms
Server debug shows content arriving, e.g.:
Processing content type=mcp_server_tool_call
Processing content type=mcp_server_tool_result
AG-UI SSE stream shows no TOOL_CALL_* events for those items.
Root Cause
_emit_content only handles text, function_call, function_result, and function_approval_request. The Foundry MCP and reasoning content types are not handled and therefore return [].
Expected Fix
Add handling in _emit_content for:
mcp_server_tool_call → emit tool-call start (same as function_call mapping)
mcp_server_tool_result → emit tool-call result (same as function_result mapping)
text_reasoning → emit some progress/timing-visible event (e.g. a state/progress delta) so reasoning is not silently invisible
This makes MCP tool calls and text_reasoning visible to AG-UI consumers.
Code Sample
Error Messages / Stack Traces
Package Versions
agent-framework-ag-ui==1.0.0b260219 agent-framework-azure-ai==1.0.0rc1 agent-framework-core==1.0.0rc1
Python Version
Python 3.12
Additional Context
No response
Metadata
Metadata
Labels
Type
Projects
- Status
Activity
LEDazzio01 commentedon Feb 24, 2026
I'd like to take this one! I just had a fix merged in this same area (PR #4200 — duplicate tool_call arguments in
_emit_tool_call), so I'm familiar with the AG-UI event emission flow in_run.py.I'll start by mapping out the unhandled content types (
mcp_server_tool_call,mcp_server_tool_result,text_reasoning) and propose how they should map to existing AG-UI event types.moonbox3 commentedon Feb 24, 2026
This points to something potentially in the underlying client that isn't creating the proper Function Call type for those tools.
LEDazzio01 commentedon Feb 24, 2026
Thanks for the feedback Evan Mattson (@moonbox3)! I dug into
_responses_client.pyto understand the flow and wanted to share what I found:The client already creates dedicated MCP content types — both the non-streaming path (
_parse_response_from_openai) and the streaming path (_parse_chunk_from_openai→response.output_item.added) explicitly useContent.from_mcp_server_tool_call()formcp_callitems rather thanContent.from_function_call().This appears intentional because MCP tools carry fields that don't map 1:1 to regular function calls:
tool_name+server_name(vsname)output(vsresult)server_label/server_namefor disambiguationThe same is true for
text_reasoning— the client createsContent.from_text_reasoning()forresponse.reasoning_text.delta/doneevents.So if I'm understanding your comment correctly, there are two possible approaches:
_emit_content→ map them to AG-UIToolCall*events (preserving the MCP-specific metadata likeserver_name/tool_namedisplay names)_responses_client.pyconvertmcp_callitems tofunction_callContent types instead ofmcp_server_tool_call— but this would lose the MCP-specific metadata and change the content type semantics across all downstream consumersWould you prefer approach 2? Or were you suggesting something else entirely? Happy to adjust the PR either way! 🙂
moonbox3 commentedon Feb 25, 2026
L. Elaine Dazzio (@LEDazzio01) it does look like we need to support option 1, as you have it.
Python: Emit AG-UI events for MCP tool calls, results, and text reaso…
Fix _emit_mcp_tool_result missing predictive_handler support (microso…
Refactor MCP tool emit functions and add missing tests (microsoft#4213)
Address review feedback for microsoft#4213: review comment fixes
Python: Emit AG-UI events for MCP tool calls, results, and text reaso…