add streaming brief#43
Conversation
|
|
||
| ## Key Requirements: | ||
|
|
||
| The requirements for MCP Tools are to: |
There was a problem hiding this comment.
nit: this may go beyond tools (e.g. streaming resources)
| - Provide a common way for MCP Servers to efficiently deliver partial results Hosts. | ||
| - Signal whether updates are intended to be supervised by Model or User to allow monitoring or other interventions (steer/cancel) during the execution. | ||
| - Handle supported modalities and data types cleanly (e.g. Text, Image, Audio, Structured) | ||
| - Consider conventions for handover and connectivity to live streaming models (realtime voice or video models for example). |
There was a problem hiding this comment.
I think this is a good list for consideration. I would be ok if we didn't solve all of this in an initial streaming solution, e.g. live media streaming will be a big area with unclear model integration (IMO). It does feel important, but if v1 only solved discrete, non-live streaming then I think that would be ok. (I'd actually expect realtime media handling to warrant its own WG).
| - Handle supported modalities and data types cleanly (e.g. Text, Image, Audio, Structured) | ||
| - Consider conventions for handover and connectivity to live streaming models (realtime voice or video models for example). | ||
|
|
||
| ## Key Design Decisions: |
There was a problem hiding this comment.
I would say that relationship to Tasks is an open question, particularly for the interactive version where the user/model can interact back with the server mid-tool call. Non-task tool calls are typically considered synchronous from a model-integration point of view and having the model address an in-progress tool call would be quite a deviation in how tools work.
|
|
||
| ## Key Design Decisions: | ||
|
|
||
| - When to use MCP Apps vs. new built-ins for delivering interactive content. |
There was a problem hiding this comment.
I also think we need to consider how this works with partial results where the result of the results might not be warrented.
e.g. if I return 10k results from the table, I probably want the results streamed. Should pagination be handled by the tool protocol or the tool API?
|
|
||
| ## Key Design Decisions: | ||
|
|
||
| - When to use MCP Apps vs. new built-ins for delivering interactive content. |
There was a problem hiding this comment.
Need to make sure that the design goals/constraints work well together with Tasks - making sure that it is clear to Users of the Protocol when/how Tool Streaming would interact with Tasks.
|
|
||
| ## Key Design Decisions: | ||
|
|
||
| - When to use MCP Apps vs. new built-ins for delivering interactive content. |
There was a problem hiding this comment.
@kurtisvg -- need to be clear on working with the limitations of JSON-RPC.
|
|
||
| ## Key Design Decisions: | ||
|
|
||
| - When to use MCP Apps vs. new built-ins for delivering interactive content. |
There was a problem hiding this comment.
@markdroth -- understand how this works with existing event streams, ordering, need for bidirectional comms.
| The requirements for MCP Tools are to: | ||
| - Provide a common way for MCP Servers to efficiently deliver partial results Hosts. | ||
| - Signal whether updates are intended to be supervised by Model or User to allow monitoring or other interventions (steer/cancel) during the execution. | ||
| - Handle supported modalities and data types cleanly (e.g. Text, Image, Audio, Structured) |
There was a problem hiding this comment.
Define tools and behaviour early --
@evalstate to get agent/multimodal examples, @kurtisvg / team to help with large data xfer.
3 participants
Add Streaming Tools brief to start working group.