fix: handle agent_tool_request event type and fix expects_response default#34
Merged
shiragannavar merged 3 commits intomainfrom Dec 11, 2025
Merged
Conversation
…fault - Add support for 'agent_tool_request' event type alongside 'client_tool_call' - Parse nested 'agent_tool_request' object in addition to 'client_tool_call' - For new agent_tool_request format: default expects_response to true for client tools - Maintain backward compatibility: legacy client_tool_call format still defaults to false Fixes issue where client tools with expects_response:true in config were not receiving the field in the event payload, causing sendToolResult() to fail.
Previously, expects_response only defaulted to true for agent_tool_request events with tool_type: 'client'. This fix extends the default to ALL client tool events (both client_tool_call and agent_tool_request) when the field is missing from the payload. Rationale: The server may not include expects_response in the payload even when the tool configuration has expects_response: true. Since client tools primarily exist to execute on the client and return results to the agent, defaulting to true is the safer and more expected behavior. This fixes issues where: - client_tool_call events without expects_response field - agent_tool_request events without tool_type field Both now correctly default to expects_response: true. BREAKING CHANGE: Client tools that previously relied on the false default and did NOT send responses will now be expected to send responses. Such tools should explicitly set expects_response: false in their configuration.
Collaborator
Author
|
Backend fix was merged into main Can you please re-review this PR? |
…ault Added 14 tests covering: - client_tool_call with explicit expects_response true/false - client_tool_call without expects_response field (should default to true) - client_tool_call with null expects_response (should default to true) - agent_tool_request with tool_type client (should default to true) - agent_tool_request with explicit expects_response false - agent_tool_request without tool_type (should still default to true) - Parameter parsing (string, numeric, boolean, empty) - Edge cases (unknown event type, malformed JSON)
PaulAsjes
approved these changes
Dec 11, 2025
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
2 participants
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.
Summary
Fixes issue where client tools configured with
expects_response: truewere not working, causingsendToolResult()to break the connection.Root Cause: The server sends
agent_tool_requestevent type, but the SDK only handledclient_tool_call. Additionally, the server doesn't include theexpects_responsefield in the payload (it's only in the tool configuration), so the SDK was defaulting tofalse.Changes
agent_tool_requestevent type alongsideclient_tool_callagent_tool_requestobject in addition toclient_tool_callagent_tool_requestformat: defaultexpects_responsetotruefor client tools whentool_type: "client"client_tool_callformat still defaults tofalseEvent Format Comparison
What SDK expected:
{
"type": "client_tool_call",
"client_tool_call": {
"tool_name": "...",
"expects_response": true
}
}What server sends:
{
"type": "agent_tool_request",
"agent_tool_request": {
"tool_name": "...",
"tool_type": "client",
"tool_call_id": "..."
}
}## Backward Compatibility
✅ Fully backward compatible - no breaking changes for existing deployments
expects_responsein payloadclient_tool_calltruetrueclient_tool_callfalsefalseclient_tool_callfalse(unchanged)agent_tool_requesttruetrueagent_tool_requestfalsefalseagent_tool_requesttool_type: clienttrue(new)Testing
sendToolResult()now works correctly without breaking the connection