Support Stream tool result?

[He-Pin]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

With the current design, a single invocation to tool need to return the content list as a whole, it would be nice to have that support streaming.

eg:
instead of:

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Failed to fetch weather data: API rate limit exceeded"
      }
    ],
    "isError": true
  }
}

It would be nice :

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "this is the first content"
      }
    ],
    "hasMore": true,
    "isError": false
  }
}

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Failed to fetch weather data: API rate limit exceeded"
      }
    ],
    "hasMore": false,,
    "isError": true
  }
}

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[itsaphel]

I suppose this would enable a downstream client to process the data in logical chunks. But what would be a realistic use case?

[He-Pin]

There are models which is streaming responses.

[WEN-JY]

I totally agree！！
when mcp server requests a remote llm model，we need to support stream response so we know things are working which makes better user experience

[kentcdodds]

I think it would be more useful for the streamed content to be more granular than just chunks of content:

HTTP/1.1 200 OK
Content-Type: multipart/mixed; boundary=boundary

--boundary
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 4,
  "hasMore": true,
  "isError": false
}

--boundary
Content-Type: text/plain

this is the first content
this is the next chunk
...

--boundary--

This would allow tools to stream the result of an LLM output for example.

[jonathanhefner]

I don't think it's strictly necessary to have "raw" content chunks. For example, the server could send content chunks as JSON-RPC notifications, and the client could extract the content just as it would from a non-chunked tool result. That would let us keep the tooling focused on JSON-RPC.

[kentcdodds]

Do you mean sending them like this?

HTTP/1.1 200 OK
Content-Type: multipart/mixed; boundary=boundary

--boundary
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 4,
  "hasMore": true,
  "isError": false
}

--boundary
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 4,
  "chunk": "this is the first content\nthis is the next chunk\n..."
}
...

I think it's unnecessarily verbose.

[jonathanhefner]

No, I was thinking sending them as SSE events, so Content-Type would be part of the payload.

[kentcdodds]

Gotcha. Doing it that way would make it more transport independent as well which is good 👍

[anfernee-cyanoly]

I have a similar user case in which the tool exposed by a MCP server is actually an agent powered by LLM, streaming its output will have much better UX, and also "agent as tool" is a common design pattern, it could be good to have native support for it

[kentcdodds]

This PR should handle this use case in a transport-agnostic way: #776