Initial clarification: This topic is NOT about “Streamable HTTP” - it, and also SSE, and also STDIO, are all bidirectional async protocols.
I want to write an serial-port mcp to communicate with IoT devices (esp32, arduino, rPI) and their terminals and sensor data outputs and so on. A dedicated serial handler is needed, because different boards use different combinations of high/low signals over DTR/RTS lines to indicate readiness or mode (DFU or USER) - and, unfortunately, if you don’t get those right, your pc/mac can inadvertently hold the board in reset indefinitely… but I digress…
From what I’ve seen, even though all MCP transports are streaming-capable, the MCP implementations to-date (and protocol/clients too) all seem to disregard this feature, and do nothing other than request → reply REST style stateless transactions?
Has anyone or anything considered how to get “not all ready at once” data back from an MCP call?
Anyone got any tips or links I could check out or think about? It’s kindof amusing - every LLM streams to us - it’s in our face all day every day - but I’ve never seen ways to do “the other way” through MCP.
How do the voice people do this? You know - the ones where the AI needs the speech-to-text input streamed in real-time, so it can plan the reply before the caller stops speaking, to reduce latency ? Can MCP send MRPC back to Cursor/etc ?