fix(mcp): reconcile live agent tool snapshots - #4367
Conversation
Co-authored-by: openhands <openhands@all-hands.dev>
|
👋 This PR needs a couple of things fixed before OpenHands can review it:
Push an update once this is addressed and this check re-runs automatically. This is an automated check - no AI was used to generate this comment. |
1 similar comment
|
👋 This PR needs a couple of things fixed before OpenHands can review it:
Push an update once this is addressed and this check re-runs automatically. This is an automated check - no AI was used to generate this comment. |
|
🚦 CI is currently failing on this PR's latest commit. Please fix the failing checks before OpenHands reviews it - this is re-checked automatically once you push a new commit. (A maintainer can also request This is an automated check - no AI was used to generate this comment. |
Co-authored-by: openhands <openhands@all-hands.dev>
Co-authored-by: openhands <openhands@all-hands.dev>
Co-authored-by: openhands <openhands@all-hands.dev>
|
@VascoSch92, would you be willing to help review this PR? Our current production use case requires MCP tools to be added, updated, and removed dynamically while an agent conversation is running. In particular, when an MCP server emits Please feel completely free to change any part of this PR, push an alternative implementation, or reimplement the approach from scratch if you see a cleaner design. We care more about getting the SDK behavior and extension boundary right than preserving the current code. Thank you very much for your time and help! |
neubig
left a comment
There was a problem hiding this comment.
Approved: live MCP tool reconciliation is sound, with focused and full CI coverage verified.
HUMAN:
This is a capability I need in practice. Our work requires tools to be updated dynamically, and OpenCode already supports this behavior.
Agent-assisted validation: I reviewed the output from the real FastMCP streamable-HTTP integration tests.
They verified dynamic tool addition, invocation, removal, re-advertisement, and same-name schema replacement.
AGENT:
Why
notifications/tools/list_changedcurrently updatesMCPClient.tools, but a running agent only receives newly added definitions. Removed tools remain exposed by the agent, and same-name schema changes keep the stale definition and validation model. This completes the stale-runtime behavior identified in the review of #3894 and tracked by #4059.Summary
MCPClient, preserving the existingMCPToolProvidercontract.Issue Number
Follow-up to #4059 and #3894.
How to Test
Run:
Observed on the current PR head:
178 passed in 9.93s. This includes a real FastMCP streamable-HTTP server that emitsnotifications/tools/list_changed; the test verifies that a dynamically added tool is callable, disappears from both client and agent after removal, and is callable again after re-advertisement. A focused unit test also warms the old validation model, changes the same tool name to a new input schema, and verifies the new schema accepts new arguments and rejects the old arguments.Run the repository checks on all changed files:
Observed: Ruff format/lint, pycodestyle, Pyright, import rules, and tool registration checks all passed.
Video/Screenshots
Not applicable; this is SDK runtime behavior covered by the real FastMCP integration test.
Type
Notes
The public
on_tools_changedcallback keeps its additions-only contract. TheMCPToolProvider.create_tools()signature is unchanged, so existing custom providers remain compatible. Reconciliation is attached to the returnedMCPClient; historical action and observation events are untouched.