Skip to content

feat(tools): standard annotation classes #235

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

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

scottslewis
Copy link

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.

  • Bug fix (non-breaking change which fixes an issue)
  • [ X] New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

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

annotation classes.  Added ToolResult, ToolAnnotation, and
ToolAnnotations annotations.   Added ToolGroupService interface and
supporting tools.utils.*Description classes, to allow runtime querying
of an service interface class' ToolDescriptions (one for each method
with Tool annotation at runtime).
@scottslewis scottslewis requested a review from Yedfree May 20, 2025 01:31
@scottslewis scottslewis marked this pull request as draft May 20, 2025 01:31
@scottslewis scottslewis marked this pull request as ready for review May 20, 2025 01:32
@scottslewis
Copy link
Author

I've significantly simplified the design of the annotation classes. Now, they only provide the McpSchema meta-data as annotation properties. e.g. for Tool interface:


@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Tool {

	String name() default "";

	String description() default "";

	ToolAnnotation[] annotations() default {};

}

Also similarly simplified the ToolParam annotation:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.PARAMETER)
public @interface ToolParam {

	String name() default "";

	String description() default "";

	boolean required() default true;

}

and added optional ToolResult annotation

Also created classes: io.modelcontextprotocol.tools.util.*Description classes that use reflection to create instances with annotation content at runtime.

@scottslewis scottslewis changed the title Annotation classes to support variety of frameworks/tools feature: standard annotation classes to support variety of frameworks May 20, 2025
@scottslewis scottslewis changed the title feature: standard annotation classes to support variety of frameworks feat: standard annotation classes to support variety of frameworks May 20, 2025
@scottslewis scottslewis changed the title feat: standard annotation classes to support variety of frameworks feat(tools): standard annotation classes May 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant