Simplify filtering MCP ToolCallbackProviders for ToolCallingAutoConfiguration

[quaff]

I think febf86c introduced unnecessary complexity, this commit make the code more simple and readable.

Did I miss something? @Kehrlann

[Kehrlann]

@quaff your current architecture introduces a dependency cycle, specifically in the case of sampling:

McpClient -> methods annotated with @McpSampling -> ChatClient (to do the sampling) -> ToolCallingManager -> ToolCallingResolver -> McpToolCallbackProvider -> McpClient

But since the "methods annotated with @McpSampling" do not have a declared dependency in the container (but work with some temporal coupling), sampling will fail.

Please run StreamableMcpAnnotationsWithLLMIT and observe the problem. These tests are not run in the PRs checks I think, because they need an Anthropic API key. That's why I inject the ToolCallbackResolver in the test rather than an object provider.

Note that this area is currently in flux, and this complicated code might go away (or at least be moved out)

[quaff]

@quaff your current architecture introduces a dependency cycle, specifically in the case of sampling:

McpClient -> methods annotated with @McpSampling -> ChatClient (to do the sampling) -> ToolCallingManager -> ToolCallingResolver -> McpToolCallbackProvider -> McpClient

I force pushed commit to use ObjectProvider.stream(Predicate<Class<?>> customFilter) for breaking the dependency cycle.

Please run StreamableMcpAnnotationsWithLLMIT and observe the problem. These tests are not run in the PRs checks I think, because they need an Anthropic API key. That's why I inject the ToolCallbackResolver in the test rather than an object provider.

Sorry I can't access Anthropic in my area, could you run it to verify? @Kehrlann

[Kehrlann]

I force pushed commit to use ObjectProvider.stream(Predicate<Class<?>> customFilter) for breaking the dependency cycle.

Yes, that's much better 👏
We're reworking tool handling and the cyclic dependency should not be a problem anymore. Let's keep this PR open until the other work has landed, and see if we still need this.

Sorry I can't access Anthropic in my area, could you run it to verify? @Kehrlann

Ah, good point. Feel free to update the test locally to use whatever model suits you best, as long as it supports tool calling.

[ilayaperumalg]

For backwards compatibility, Would this work if there is a List instead of just multiple ToolCallbackProvider instances?

[quaff]

List<ToolCallbackProvider> bean will not be injected via ObjectProvider<ToolCallbackProvider>, but I don't think anyone would do that, and ObjectProvider<ToolCallbackProvider> is the recommended way by Spring Boot, you can refer to other AutoConfigurations.

[ilayaperumalg]

I agree on using ObjectProvider being the better approach. My question is mainly about backwards compatibility. Since we already had "List tcbProviders", we don't want to break the compatibility for those who already uses "List tcbProviders". Perhaps, we should use ObjectProvider<List>. cc @tzolov

[tzolov]

I believe #4851 is a replacement for this PR