feat: client support for setting ToolAnnotations #513
Conversation
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
- Added a function in Client to set tool annotations received from server - Updated Client builder to support configuring ToolAnnotations - Enables downstream clients to handle server-provided tool metadata
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.
Motivation and Context
When local function_call logic is split into an MCP Server service, metadata such as returnDirect may be lost, causing inconsistent semantics after service splitting. This change adds support in the MCP Java SDK Client for setting ToolAnnotations and provides builder configuration to enable preservation and propagation of server-provided metadata.
When directly accepting properties from an MCP server, some attributes may be unsafe or potentially destructive. Therefore, the client should enforce its own priorities. For example, by default, returnDirect should always be treated as false unless explicitly overridden in a controlled manner.
How Has This Been Tested?
No test classes were modified. Testing with the Docker server image was
ineffective because the server did not send the relevant attributes. Verification
was done by running the project locally, ensuring the Client correctly receives
and handles ToolAnnotations.
Breaking Changes
None. No configuration changes are required. The feature is opt-in and only
affects applications that explicitly use the SDK support (e.g., Spring AI). If
not used, it has no impact.
Types of changes
Checklist
Additional context
This feature enables the Client to optionally handle ToolAnnotations sent from the server, which was previously ignored.
By default, the Builder does not activate ToolAnnotation support; applications must explicitly configure it to take effect (e.g., in Spring AI).
The change is safe and backward-compatible: it does not affect existing functionality or code that does not use ToolAnnotations.
Provides flexibility for future features that rely on server-sent metadata without introducing breaking changes.