How to understand StreamableHTTP, yet it doesn't support streaming the results of tool calls?

[Kwan-Zeng]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

Hello,
According to the MCP protocol specification, the deprecation of SSE and the recommendation of StreamableHTTP naturally lead me to believe that tool calls in MCP should support streaming responses.

However, in actual integration—regardless of the programming language SDK used—none appear to support streaming the results of tool calls. If that’s the case, why emphasize "streaming" at all? It would be clearer and more reasonable to explicitly define tool calls as simple request-response interactions based on JSON-RPC.

I’ve noticed many others share the same confusion, as reflected in these issues:

• can we call tools and return steaming output? python-sdk#472
• Can the tool capability of MCP support streaming responses? The encapsulated tool cannot return results in one go and requires batched returns, similar to the interface capability of SSE java-sdk#711
• In streamable mode, a tool on my MCP server responds with SSE streams, and the MCP client only handles the first SSE event. java-sdk#629

I’d really appreciate your help with the following:

1. Could you please clearly confirm whether streaming the results of tool calls is truly unsupported?

2. If streaming is supported, could you provide a Java example demonstrating how to handle streamed tool-call responses?

Many of us are eager to contribute to and adopt the MCP ecosystem, and your clarification on this matter would be extremely valuable. Thank you very much!

[Dumbris]

The confusion is valid — "StreamableHTTP" is about the transport, not about tool call results being streamed.

Here's the distinction: StreamableHTTP replaces SSE as the wire protocol between client and server. It uses standard HTTP requests where the server can upgrade to streaming (via Transfer-Encoding: chunked or SSE within the response) for things like progress notifications and log messages during a long-running tool call. But the tool call result itself (CallToolResult) is still a single message — the spec doesn't define a way to incrementally stream partial tool outputs.

What the SDK issues you linked (Python #472, Java #711, #629) are asking for is essentially: "can a tool yield chunks of output as it runs?" The answer today is: not in the spec. A tool can send notifications/progress with progress tokens while working, and the final result arrives as one payload.

Why it matters: If your tool generates large output (e.g., code generation, document conversion), you're buffering the entire result server-side before sending. The workaround most people use is to have the tool write to a resource and return a resource URI, then the client reads the resource separately.

The naming is genuinely misleading — "Streamable" refers to the HTTP connection lifecycle being stream-capable, not the tool call semantics.