-
Notifications
You must be signed in to change notification settings - Fork 9
Description
I opened this issue on the mcp java sdk repo:
modelcontextprotocol/java-sdk#224
as can be seen from the discussion, it would be valuable to 'standardize' on this project's annotation classes by including the @interface types (at least) in the sdk namespace (i.e.) io.modelcontextprotocol.* and include either in the sdk jar/bundle directly, or as a separate jar/bundle.
The main reason why I think this is important is that these @interface types are directly tied to the mcp specification...e.g. for McpTool the fields 'name', 'description', @McpAnnotation, etc. For many developers of MCP tools, prompts, resources, completions, etc these annotations will be the tools that they require to create their own tools, prompts, resources, etc. Therefore, I believe these types should be coupled with the spec (in io.modelcontextprotocol sdk namespace) rather than with spring ai namespace so that all frameworks (and tools) can be used to define the necessary meta-data without having to require extra framework-specific dependencies (e.g. to spring ai).
This will also benefit tool vendors, who will be able to depend upon a close coupling between the spec, and the associated annotations. If the spec evolves (e.g. additional meta-data added), then the types can evolve in lockstep. This will benefit tools builders and the entire mcp dev community.
My own view is that the package name should be either:
io.modelcontextprotocol.annotations (with all @interface classes that are currently in org.springcommunity.mcp.annotation)
OR
io.modelcontextprotocol.tools.annotations, io.modelcontextprotocol.prompts.annotations, etc with the respective types in each *.annotations package. This would be appropriate IMHO if there are plans to have packages for 'tools', resources, prompts, etc in the sdk.
I would suggest moving the Adapter classes org.springcommunity.mcp.annotation to a different package...either io.modelcontextprotocol.util or io.modelcontextprotocol.util.something. In my opinion, it would be useful to include all the mcp.method. packages and classes, as long as they only depend only upon Java 17+, mcp java sdk, or it's current dependencies (e.g. jackson). From my initial review of things this is already the case, but I may have missed a dependency.
I'll be happy to produce prs for package/naming alternatives.