In a single turn, the model asks for two tool calls on the same MCP server. How does the client send them and match each result to its call?
Select an answer to reveal the explanation.
Short Explanation
Every tool call gets its own ticket number, and that's the JSON-RPC id. You match each answer to its ticket, not to the order it shows up in. Reusing an id is the trap.
Full Explanation
MCP messages follow JSON-RPC 2.0. A tools/call request names one tool and its arguments, so two tool calls are two separate requests. Each request MUST include a string or integer id that is not null, and the id MUST NOT match the id of any other request the sender has issued and not yet received a response for. Result responses MUST carry the same id as the request they answer, so the client correlates each response by id, regardless of arrival order. Sending one tools/call naming two tools does not match the request shape, which has a single name and an arguments object, and the result format has no array of per-tool results. Reusing one id for both in-flight requests breaks the uniqueness rule and makes correlation ambiguous; responses may arrive in any order, especially when one tool runs longer. Notifications carry no id and receive no response, so they cannot be used to invoke tools; the subscriptions/listen stream carries change notifications, not tool results. Exam caveat: on stdio all responses share stdout and are correlated by id, while on Streamable HTTP each request has its own POST and response, but id matching still applies. Operational check: capture both requests and confirm distinct ids, then confirm each response carries the id of the call it answers.