Fix Python frontend tools client sample - #452
Open
Ran Shemtov (ranst91) wants to merge 2 commits into
Open
Conversation
The client sample on the AG-UI frontend tools page could not produce the output the page shows. Running it against the Getting Started server printed only `[Run Started]` and `[Run Finished]` for any prompt that needed a tool. Four things were missing: - The tool declarations carried no parameter schema, so the model could only call a tool with an empty argument object. They now ship the JSON schema derived from each function's signature. - The event loop ignored every tool-call event. `TOOL_CALL_START` and `TOOL_CALL_ARGS` are now read, with the argument fragments accumulated per tool call id and parsed once the call is complete. - `_handle_tool_call` was never called, and expected a single event carrying a ready-made argument dictionary. It now receives the tool name and the accumulated arguments, and returns the result. - The client never sent tool results back. A frontend tool call ends the server's run, so the client now records the call and its result in the conversation and issues a follow-up run to get the agent's answer. Run boundaries are reported once per user turn rather than once per run. Verified against a live AG-UI server: the sample runs verbatim, calls both frontend tools with real arguments, and keeps history across turns.
Contributor
|
Learn Build status updates of commit db0aab0: ✅ Validation status: passed
For more details, please refer to the build report. |
The method now drives both the initial run and the follow-up run that delivers the agent's answer after a frontend tool executes, so name it run_turn rather than send_message.
Contributor
|
Learn Build status updates of commit 0d21f2f: ✅ Validation status: passed
For more details, please refer to the build report. |
Martha Kelly Schumann (marthakelly)
approved these changes
Sep 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The client sample in the Python zone of AG-UI > Frontend Tool Rendering cannot produce the output the page documents. Run against the server from the Getting Started tutorial, any prompt that requires a frontend tool prints only the run boundaries:
Prompts that need no tool answer normally, so the gap is specific to frontend tool execution.
Cause
Four things in the sample:
nameanddescriptionwere sent, so the model had no arguments it was allowed to fill and called the tool with{}.RUN_STARTED,TEXT_MESSAGE_CONTENT,RUN_FINISHEDandRUN_ERRORonly, soTOOL_CALL_START,TOOL_CALL_ARGSandTOOL_CALL_ENDfell through unhandled._handle_tool_callwas never called, and read fields that do not exist on those events. The tool name arrives astoolCallNameonTOOL_CALL_START, and the arguments arrive as JSON text fragments inTOOL_CALL_ARGS.delta, to be concatenated per tool call id and parsed atTOOL_CALL_END.Fix
Only the client code block changes. The tool declarations now ship the JSON schema derived from each function's signature, the tool-call events are read and their argument fragments accumulated per call id,
_handle_tool_callreceives the tool name and the completed arguments, and the client records the call and result in the conversation before issuing the follow-up run. Run boundaries are reported once per user turn rather than once per run, matching the documented output.The surrounding prose, the tool definitions section, the protocol description and the expected output are unchanged.
Verification
The sample was extracted from the page and run verbatim against a live AG-UI server built from the Getting Started tutorial:
Both sample tools were exercised, including
get_user_location, which takes no parameters, and conversation history was confirmed to carry across turns.