Pluggable Java-method tool-definition strategies & typed inputSchema in MCP

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 this
approach. The main issues are:

• Only @Tool annotations are considered. There’s no way to plug in an
  alternative strategy for creating tool definitions.
• Parameter names are extracted from the bytecode. Without the -parameters
  compiler flag, descriptive names aren’t available.

I propose the following enhancements:

1. Allow injection of alternative strategies for generating tool definitions
   from different kinds of method metadata. The strategy based on
   @Tool annotations could remain one of the built-in options.
2. Introduce a clear mapping between tool-definition parameter names and the
   original Java method parameters.

Moreover, implementing this parameter mapping would be much simpler if
ToolDefinition.inputSchema were a typed object (as defined in the
MCP 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, and MethodToolCallback?

Thanks!

Start by reading the ToolDefinition, MethodToolCallbackProvider, and MethodToolCallback APIs, then compare inputSchema with the linked MCP specification. Define how alternative method-metadata strategies and parameter-name mappings should work, including the proposed typed inputSchema; the issue is done when those compatibility and design questions are resolved.