A host's stdio MCP server process crashes while two tools/call requests are in flight and a subscriptions/listen stream is open. What should the client do?
Select an answer to reveal the explanation.
Short Explanation
When your stdio server falls over, nothing it was holding survives, so you just pick up the pieces and ask again. The trap is expecting a handshake or replay to bring the old state back, because there's no state to restore.
Full Explanation
The stdio transport specifies that if the server process exits unexpectedly, the client should restart it. Because the protocol is stateless, in-flight requests are simply lost and the client can retry them against the fresh process, which is safe to reason about when the tools are idempotent and needs care when they are not. Active subscriptions/listen streams must also be re-established after restart, since the server holds no subscription state across reconnections; the subscriptions guidance says the client must re-send the listen request. Repeating an initialize handshake belongs to legacy revisions; modern requests carry protocol version and capabilities in _meta, and a fresh process has no record of earlier requests to replay. Last-Event-ID resumption is not supported in revision 2026-07-28, and on stdio there are no per-request streams to resume in any case. Letting the lost requests time out leaves the user waiting for results that will never arrive and abandons notifications the host depends on. Exam caveat: before retrying a side-effecting call, check the tool's idempotentHint or confirm with the user, because the crash may have happened after the action took effect. Operational check: kill the server process during a test call and confirm the host restarts it, retries the call, and receives a new subscription acknowledgement.