-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Pluggable Java-method tool-definition strategies & typed inputSchema in MCP #3317
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@andrey-fomin thanks for raising this issue. We should definitely add some documentation and examples on how to extend and customise the tool calling strategy, because there are actually many possibilities.
That's not true, let me explain why. The main API to provide a tool definition+execution logic is Building on top of that API, Spring AI provides a convenient built-in strategy to source Java methods as tool candidates in a declarative way, using the
The built-in That's the built-in behaviour of
When using the built-in declarative approach to define tools (via I hope this answer helps clarifying some of the points raised in this issue. |
Hi @ThomasVitale,
I’ve tried to expose the REST methods of my application using MCP, but I haven’t
found an easy way to do so. I’d like to leverage Swagger v3 annotations for
tool definitions, but
MethodToolCallbackProvider
doesn’t support thisapproach. The main issues are:
@Tool
annotations are considered. There’s no way to plug in analternative strategy for creating tool definitions.
-parameters
compiler flag, descriptive names aren’t available.
I propose the following enhancements:
from different kinds of method metadata. The strategy based on
@Tool
annotations could remain one of the built-in options.original Java method parameters.
Moreover, implementing this parameter mapping would be much simpler if
ToolDefinition.inputSchema
were a typed object (as defined in theMCP specification)
instead of a raw JSON string. This would allow implementations to assume that
parameters in the tool definition appear in the same order as in the bytecode.
Would it be feasible to introduce these backward-incompatible changes to
ToolDefinition
,MethodToolCallbackProvider
, andMethodToolCallback
?Thanks!
The text was updated successfully, but these errors were encountered: