feature: support async mcp tool client

[wenhaozhao]

support async-mcp-client

[Poggecci]

Thank you a lot for this contribution!
Would you mind updating the description briefly detailing why the Async client was necessary for your use case? Would love to better understand and see if we should update our docs to default to the Async over the sync client

[wenhaozhao]

Thank you a lot for this contribution! Would you mind updating the description briefly detailing why the Async client was necessary for your use case? Would love to better understand and see if we should update our docs to default to the Async over the sync client

Thanks for you relay.

I am building an Agent service based on Java, providing RESTful APIs through Spring Boot Webflux. ADK-Java meets my needs. Meanwhile, it is developed based on RxJava. Although it and Reactor in Webflux are two different reactive frameworks, it's not a problem. Asynchronous and reactive technology stacks are exactly what I want. But in the process of me gradually delving into using ADK, I found that in the link based on the asynchronous technology stack:

1 McpTool is actually an implementation based on McpSyncClient.
2 And mcp-java-sdk is an asynchronous implementation based on Reactor, providing asynchronous APIs through McpAsyncClient. McpSyncClient converts asynchronous APIs to synchronous APIs by means of Mono.block().
Thus, the call link of Async -> Sync -> Async is formed for McpTool in ADK.
However, the key point is that using blocking operations in an asynchronous context may lead to performance problems and waste of thread resources.
So, I decided to provide an asynchronous implementation of McpTool to better match the asynchronous technology stack architecture of ADK.

[wenhaozhao]

Thank you a lot for this contribution! Would you mind updating the description briefly detailing why the Async client was necessary for your use case? Would love to better understand and see if we should update our docs to default to the Async over the sync client

Thank you a lot for this contribution! Would you mind updating the description briefly detailing why the Async client was necessary for your use case? Would love to better understand and see if we should update our docs to default to the Async over the sync client

Thanks for you relay.

I am building an Agent service based on Java, providing RESTful APIs through Spring Boot Webflux. ADK-Java meets my needs. Meanwhile, it is developed based on RxJava. Although it and Reactor in Webflux are two different reactive frameworks, it's not a problem. Asynchronous and reactive technology stacks are exactly what I want. But in the process of me gradually delving into using ADK, I found that in the link based on the asynchronous technology stack:

1 McpTool is actually an implementation based on McpSyncClient. 2 And mcp-java-sdk is an asynchronous implementation based on Reactor, providing asynchronous APIs through McpAsyncClient. McpSyncClient converts asynchronous APIs to synchronous APIs by means of Mono.block(). Thus, the call link of Async -> Sync -> Async is formed for McpTool in ADK. However, the key point is that using blocking operations in an asynchronous context may lead to performance problems and waste of thread resources. So, I decided to provide an asynchronous implementation of McpTool to better match the asynchronous technology stack architecture of ADK.

So, I think it's a better choice to use asynchronous clients in the asynchronous link.

[andrey-star]

Can we also either update core/src/main/java/com/google/adk/tools/mcp/McpToolset.java to allow choosing, or create an McpAsyncToolset?

[wenhaozhao]

In my opinion, it might be better to create an McpAsyncToolset first, and then gradually and smoothly migrate the McpToolset to McpAsyncToolset.

[wenhaozhao]

I'll add McpAsyncToolset later

[wenhaozhao]

Can we also either update core/src/main/java/com/google/adk/tools/mcp/McpToolset.java to allow choosing, or create an McpAsyncToolset?

The pr for McpAsyncToolset: #306