feat: Add _meta to tool/prompt/resource declaration

[vdm24]

Append the ability to define "_meta" property in tool, prompt, resource declarations

Usage:

@McpTool(metaProvider = MyMetaProvider.class)
String myTool() {
}

class MyMetaProvider implements MetaProvider {

    @Override
    public Map<String, Object> getMeta() {
        return Map.of(
            "openai/widgetPrefersBorder", true,
            "openai/widgetDomain", "https://chatgpt.com",
            "openai/widgetCSP", new WidgetCsp());
    }
}

Issue: #81

[vdm24]

Hi everyone,

is this "community" project alive?

It has been nearly three weeks since the PR was opened, but there hasn’t been any reaction from maintainers - no comments, no reviews, no even an emoji. This lack of activity seems weird for a Spring project...

[valery1707]

It has been nearly three weeks since the PR was opened, but there hasn’t been any reaction from maintainers - no comments, no reviews, no even an emoji. This lack of activity seems weird for a Spring project...

I have PR spring-projects/spring-ai#3666 with almost half year of inactivity ... but with some reaction, but only after about 3 months ...

[embesozzi]

In version 1.1.2, it supports defining at least some annotations.

   annotations = @McpTool.McpAnnotations(
                    title = "",
                    readOnlyHint = true,
                    destructiveHint = false,
                    idempotentHint = true
            )

[scottslewis]

For all information:

There are active discussions around moving the MCP - specified annotation types in this package to the mcp-java-sdk

modelcontextprotocol/java-sdk#491

and

#10

this would likely mean a new package in the mcp-java-sdk package namespace (e.g.io.modelcontextprotocol.annotation or io.modelcontextprotocol.spec.annotation, etc).

A main reason for such a move of annotation classes from mcp-annotation to mcp-java-sdk is that the annotations are completely specified by the MCP protocol spec...which defines the specific meta-data that the tooling can provide...e.g. @mcptool fields correspond to the specification schema of Tool properties....i.e. description, title, name, annotation

If there is consensus in this and the mcp-java-sdk projects around a move/refactor of annotation classes from mcp-annotations to new io.modelcontextprotocol.annotation package, I will produce a pull request to the mcp-java-sdk project that adds all the annotation types currently defined in mcp-annotations.

If there is consensus around the solution provided above (MetaProvider) it could be added as part of this refactor.

[ralfstuckert]

I get the point that there is quite movement in all those APIs, SDKs, whatsoever...but AI in general is moving fast. So in the meantime it would be helpful to have a general way to provide any metadata in order to work with all those new ideas, so these ideas can evolve and stabilize.

[vdm24]

Hi @embesozzi ,
This PR is not related to MCP-protocol annotations, it's about providing _meta property in tool/prompt/resource declaration.

[witzatom]

Thanks for this MR, I hope it gets in!

I just want to say, that the spring ai mcp framework not supporting the _meta field is not a small thing. It means it does not follow the MCP spec, at least since https://modelcontextprotocol.io/specification/2025-06-18/basic/index#meta. So I support getting things fixed here, even if there are plans to move/refactor, and especially if the MR looks good.

[tandrup]

Agree. I'm also lacking the _meta property for some tools I'm building.

[embesozzi]

I’ve been using Spring AI focus in MCP, and it often seems to lag a few steps behind the latest specs. If staying up to date with those specs is important, you might want to consider a different framework, as this can otherwise become a consistent blocker. That said, Spring itself is a great framework.

[vdm24]

@embesozzi Which framework would you recommend for MCP?

[scottslewis]

I'm proposing a public, dev-community-run open source project and team to define framework-agnostic, spec-compliant, mcp java annotations classes, including support for meta.

[tzolov]

Thanks @vdm24 , the meta-provider approach looks great! There's a related PR (#102) by @apappascs, though the json-text annotation attribute is not optimal approch.

@habuma is reviewing both PRs and will suggest changes — is it OK to push them to your PR?

[vdm24]

@tzolov Sure, no problem.

[habuma]

@vdm24 I've taken a look at this PR and it's really good. I particularly like the use of a metadata provider to keep the annotation clean. The only problem I saw is that there were a few places where the metadata wasn't being transferred to the underlying resource objects. Meanwhile, the work in PR (#102) by @apappascs covered those things.

I attempted to merge the code from both PRs together and it worked quite well. If it's all the same to both of you, I'd like to merge my branch (which is a combination of both PRs) onto one or the other PR branch and then merge into main from there. Sound good?

[apappascs]

Thank you for taking a look, @habuma.
Sounds good to me. Please let me know if there is anything I can help with.

@vdm24 I've taken a look at this PR and it's really good. I particularly like the use of a metadata provider to keep the annotation clean. The only problem I saw is that there were a few places where the metadata wasn't being transferred to the underlying resource objects. Meanwhile, the work in PR (#102) by @apappascs covered those things.

I attempted to merge the code from both PRs together and it worked quite well. If it's all the same to both of you, I'd like to merge my branch (which is a combination of both PRs) onto one or the other PR branch and then merge into main from there. Sound good?

[habuma]

Quick followup: I had originally thought to merge the work onto this PR's branch, but then realized that I can't really do that because this PR's branch is in @vdm24 's clone. So, after I do a bit more testing, I plan to push a feature branch that contains the results of merging #102 onto #83 (and then cleaning up conflicts) and create a new PR from it. From there, I'll invite both @vdm24 and @apappascs to review the feature branch and...if it is acceptable...merge onto main.

Let me know if you have any concerns with this plan.

[scottslewis]

For all info: There is an effort to define a small set of annotations classes that are cross-framework. Support for meta exists (MetaField).

[tzolov]

@vdm24 , @apappascs and @habuma thank you for the great, combined, effort to design and implement this feature!

[tzolov]

This PR has been merged as part of the c7ffe98, thank you @vdm24

[lucaspouzac]

Is it possible to generate a new tag to test this feature, please 🙏 ?