https://google.github.io/adk-docs/tools/mcp-tools/
The current implementation of MCPToolset in ADK supports connecting to MCP servers via StdioServerParameters and SseServerParams. While SseServerParams is suitable for server-sent events, the general call_tool mechanism appears to be designed for discrete, fully-buffered responses, as shown by the return type list[mcp_types.Content].
This creates a limitation for MCP tools that need to return large data payloads, such as downloading a large file, streaming a database query result, or accessing a continuous data feed. Under the current model, the MCP server would have to buffer the entire response in memory before sending it, which is inefficient and can lead to memory exhaustion for both the server and the ADK client.
Proppsal enhancing MCPToolset to support handling streamable HTTP responses from call_tool invocations.
When an ADK agent calls an MCP tool that returns a streaming body (e.g., with Transfer-Encoding: chunked or a large Content-Length), the MCPToolset should not attempt to buffer the entire response. Instead, it should provide the response as a streamable object to the agent, such as an async_iterator.
This would allow the agent to process the data chunk-by-chunk, enabling efficient handling of large data payloads without significant memory overhead. The result of the tool call could be a special Artifact type that represents the live stream.
Server-side Pagination: The MCP tool could implement custom pagination, forcing the agent to make multiple call_tool requests to fetch data in chunks. This adds significant complexity to the agent's logic and increases latency.
Intermediate Storage: The MCP tool could save the large file to a shared location and return a URL or path. The agent would then need a second tool to read the data. This is an indirect, multi-step workflow that is less efficient.
This feature is crucial for building agents that can interact with data-intensive, real-world systems. For example, an agent could call a tool to fetch_large_dataset() and pipe the resulting stream directly to another tool for processing, all within a memory-efficient, asynchronous workflow. This aligns perfectly with the asyncio foundation of ADK and would greatly expand its capabilities for enterprise use cases.
https://google.github.io/adk-docs/tools/mcp-tools/
The current implementation of MCPToolset in ADK supports connecting to MCP servers via StdioServerParameters and SseServerParams. While SseServerParams is suitable for server-sent events, the general call_tool mechanism appears to be designed for discrete, fully-buffered responses, as shown by the return type list[mcp_types.Content].
This creates a limitation for MCP tools that need to return large data payloads, such as downloading a large file, streaming a database query result, or accessing a continuous data feed. Under the current model, the MCP server would have to buffer the entire response in memory before sending it, which is inefficient and can lead to memory exhaustion for both the server and the ADK client.
Proppsal enhancing MCPToolset to support handling streamable HTTP responses from call_tool invocations.
When an ADK agent calls an MCP tool that returns a streaming body (e.g., with Transfer-Encoding: chunked or a large Content-Length), the MCPToolset should not attempt to buffer the entire response. Instead, it should provide the response as a streamable object to the agent, such as an async_iterator.
This would allow the agent to process the data chunk-by-chunk, enabling efficient handling of large data payloads without significant memory overhead. The result of the tool call could be a special Artifact type that represents the live stream.
Server-side Pagination: The MCP tool could implement custom pagination, forcing the agent to make multiple call_tool requests to fetch data in chunks. This adds significant complexity to the agent's logic and increases latency.
Intermediate Storage: The MCP tool could save the large file to a shared location and return a URL or path. The agent would then need a second tool to read the data. This is an indirect, multi-step workflow that is less efficient.
This feature is crucial for building agents that can interact with data-intensive, real-world systems. For example, an agent could call a tool to fetch_large_dataset() and pipe the resulting stream directly to another tool for processing, all within a memory-efficient, asynchronous workflow. This aligns perfectly with the asyncio foundation of ADK and would greatly expand its capabilities for enterprise use cases.