How to get the _meta parameter in tools/call

[cjpnice]

How to get the _meta parameter in tools/call

[quaff]

See https://docs.spring.io/spring-ai/reference/1.1-SNAPSHOT/api/mcp/mcp-annotations-special-params.html#_mcpprogresstoken

[tzolov]

@cjpnice , @quaff Here are the general rules (available in 1.1.0-SNAPSHOT and 1.1.0-M1):

MCP Server Side

• If using the dedicated mcp-annotations like @McpTool, @McpPrompt ... then you can either

  • (1) add the McpMeta argument that provides access to metadata from MCP requests, notifications or
  • (2) use the @McpProgressTooken to obtain the MCP request progress token.

• If you are using the @Tool then consider adding the ToolContext argument.
  Later is auto-populated with the MCP request meta.

MCP Client Side

• On the Spring AI client side use the ChatClient's .toolContext(...) to pass the metadata including the progressToken:

  ChatClient chatClient = ...
  
  String response = chatClient
          .prompt("Tell me more about the customer with ID 42")
          .toolContext(Map.of("progressToken", "my-progress-token"))
          .call()
          .content();

  Find more info at the Tool Context to MCP Meta Converter.

[DannySortino]

@tzolov I actually have a question on the above suggestion for the server side... I was struggling to figure out why i was not getting my progressToken being passed from my client side to server side. I checked the JSONRPC and it looked good, but when my toolContext was passed through, it had ONLY the exchange key in it.

I looked at the implementation and see that in McpToolUtils.toSharedSyncToolSpecification (looking at 1.1.0-M2) when it does the toolCallback.call it ignores all the _meta passed in from the request, and just creates a new ToolContext for the MCP_EXCHANGE_KEY. I would have thought this would combine the fields from the _meta and the EXCHANGE_KEY to allow passing through the fields to the toolContext.

[tzolov]

@DannySortino thanks for the feedback. This sounds like an issue. I’ll have a look and if necessary fix it for M3

[tzolov]

@DannySortino i don't have much time to look at this today so this would likely slip to M4

[DannySortino]

Just to add some more details to what I was seeing above -

With SYNC server, it is where I noticed the _meta present in McpToolUtils.toSharedSyncToolSpecification and then being erased...

With ASYNC server, behaviour is slightly different - the _meta is actually null by that point. It seems that during the McpServerFeatures.AsyncToolSpecification(Tool, Bifunction) found in MCP.core that is being used will only pass the arguments, and any metadata is lost. Looks like it is mostly caused by Spring-Ai McpToolUtils.toAsyncToolSpecification using the deprecated AsyncToolSpecification(Tool, Bifunction) and not the new Record format of AsyncToolSpecification(Tool, Bifunction, Bifunction) - in which the first bifunction is deprecated, but the second is the actual one to hold the tool call, and instead of passing through an arbitrary Map<String, Object> would pass through the entire callToolRequest object, which contains the metadata. Then, with the fix to toSharedSyncToolSpecification to combine the meta map and the exchange for toolContext would expose all the metadata.

So from what I can see the fixes needed are:

1. McpToolUtils.toSharedSyncToolSpecification instead of creating a new toolContext with just exchange, combine with the _meta map that came in on the request - Update: I tested this shaded on my application with this suggested fix, and now have the toolContext properly populated with data other than just exchange.
2. McpToolUtils.toAsyncToolSpecification instead of using deprecated method of constructing the AsyncToolSpecification, use the newer record approach to have a biFunction that passes the callToolRequest through - same code fix that was seemingly done for McpToolUtils.toSyncToolSpecification but not McpToolUtils.toAsyncToolSpecification - Update: This one looks to have been fixed as part of a refactor to use builder here - 8a2d86b

More than happy to contribute the changes if you are busy elsewhere, and agree with the above @tzolov