Annotation classes to support variety of frameworks/tools #235
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.
This pr defines two annotation classes (Tool and ToolParam) and one support interface class ToolCallResultConverter.
As per issue #224 it would be helpful if the mcp java sdk had these annotation classes so that tools builders didn't need to create their own/duplicate separate annotations for each tool suite. As things are now, java tooling and framework builders are creating their own Tool and ToolParam annotation classes, making it difficult to be tooling vendor independent wrt building mcp servers.
Motivation and Context
Having these classes as part of the mcp sdk would allow vendor neutral mcp servers to be more easily created.
Breaking Changes
This should supersede the tooling and framework-specific annotation classes each framework vendor is using.
Additional context
Obviously, these annotation classes are very much like the vendor-specific versions currently being deployed. I would suggest that this change be made before/as part of 1.0.0 release of mcp sdk.
I've intentionally left off any copyright notice, license, or documentation. Any appropriate for this project is fine with me. I would expect that wrt documentation links to the specification fields (e.g. description) could be provided. I would not object to changing package structure or other naming. This is just a suggestion