A team moves an MCP server from stdio to Streamable HTTP. A teammate worries that tools/call results will need a different structure on the new transport. What is accurate?
Select an answer to reveal the explanation.
Short Explanation
Switching transports is like moving a letter from the post to a courier — the words inside don't change. Your tools/call results look the same on stdio and Streamable HTTP. Only the delivery mechanics differ.
Full Explanation
The transports overview states that protocol semantics are identical on every transport. A transport is a binding that defines how messages are framed and delivered, how request metadata is carried, and how cancellation and termination are signalled; it does not define what messages mean. The message patterns, including request and response, multi round-trip requests and subscribe and notify, are part of the core protocol and are the same on every binding. A tools/call result therefore has the same JSON-RPC structure over stdio and over Streamable HTTP. Streamable HTTP does not wrap results in a renamed envelope; the response body is a JSON-RPC message, delivered either as application/json or on a request-scoped event stream. Multi round-trip requests are not limited to stdio, because InputRequiredResult is an ordinary result and works on any transport. Streamable HTTP keeps the same JSON-RPC method names; it adds headers such as MCP-Protocol-Version, Mcp-Method and Mcp-Name that mirror body fields for intermediaries, while the body remains the source of truth. Exam caveat: transport-specific rules do differ, for example cancellation is a notification on stdio but closing the response stream on HTTP, and authorization applies only to HTTP. Operational check: run the same tools/call over both transports and compare the JSON-RPC result bodies for equality.