chore: Add ToolContextCreator.

[He-Pin]

Motivation:
Add an extension point for users to extend and create a subclass of ToolContext

[ThomasVitale]

@He-Pin thanks for your contribution. Could you share some more details about your use case for such a change? Thanks!

[markpollack]

interested as well - related to the other PR, this enables an execution strategy for tools. Also, as this would require some tests cases before merging.

[He-Pin]

We are building an mcp proxy server and need some extension point.

I will share more detail once I leave the airport

[ThomasVitale]

@He-Pin thanks, looking forward to that! It sounds a very interesting use case! The ToolCallingManager is an interface, so it should be easy to customise to support more use cases. The DefaultToolCallingManager is just an example of a default implementation. Before changing the default implementation by introducing new APIs, I would suggest considering whether a separate implementation would work, which should guarantee full flexibility and customisations. That was the intent behind the ToolCallingManager API.

If you define your custom ToolCallingManager as a bean, Spring AI will pick it up and use it instead of DefaultToolCallingManager automatically.

@Bean
ToolCallingManager myToolCallingManager() {
    return new MyMcpToolCallingManager();
}

Inside MyMcpToolCallingManager, if there's a functionality you don't need to customise, you can also delegate to DefaultToolCallingManager.

I'm mentioning this also considering your other proposal: #2855.

[He-Pin]

yes, thanks for that , but another thing is the current ToolContext is final, and then we can only put our CTX as an special field in it, if we can subclass it , we can separate our ctx from the origin CTx

It would be better that there is an addition generic CtxData ctx parameter in the call method, but that will break the current binary compatibility.

So that's what I was thinking, we can even pass our ctx with thread local, but that's not ideal

[markpollack]

@ThomasVitale what was the motivation for the ToolContext to be final?

8329402

[tzolov]

yes, thanks for that , but another thing is the current ToolContext is final, and then we can only put our CTX as an special field in it, if we can subclass it , we can separate our ctx from the origin CTx

@He-Pin what is the problem to put your CTX as a special field in the existing ToolContext?

[He-Pin]

There are more problem than we think.

1. I need to pass context data, which is extracted from the origin server request, headers, and then passed to our toolcall, but I can't , we are currently encoding the data in the JSONRPCRequest, which will need us to modify the TransportProvider, refs: feat: Add request with context support. modelcontextprotocol/java-sdk#226

2. I need separate our context from the ToolContext, or we can put our context as a field in the ToolContext

    /**
     * @param toolInput        the input to the tool
     * @param toolContext       tool context
     * @param tmcpInputContext tmcp input context
     */
    default String call(final String toolInput,
                        final @Nullable ToolContext toolContext,
                        final TmcpInputContext tmcpInputContext) {
        if (tmcpInputContext != null && !tmcpInputContext.getContext().isEmpty()) {
            throw new UnsupportedOperationException("tmcp context is not supported!");
        }
        return call(toolInput, toolContext);
    }

We extended the current ToolContext with this one, and let the method call our method, and then I need #3067

The current spring ai lack some extension point, but as you see, RC is here now :( ...