A stdio server crashes mid-session with two tool calls outstanding. A developer starts designing a mechanism to replay session state into the replacement process. Is that mechanism needed?

Mediummcpstatelessstdioreliability

Last reviewed 22 Aug 2026

No, and nothing needs retrying either, because the client resumes the outstanding calls automatically after a restart.
Yes — the new process has to be brought up to the point the old one reached before it can serve anything.
No, but the user has to reconfigure the server, since a crashed subprocess cannot be brought back by the client.
No — the protocol is stateless, so the outstanding requests are lost and can simply be retried.Correct answer

Show answer & explanation

Correct answer: D. No — the protocol is stateless, so the outstanding requests are lost and can simply be retried.

Explanation

The principle — Statelessness is not an abstract property; it is the reason a crash is cheap.

Why the key is correct — If the server process exits unexpectedly, the client SHOULD restart it. And the recovery story is one sentence long: because the protocol is stateless, any in-flight requests are simply lost and the client can retry them against the fresh process. There is no session to rebuild because there was never a session, so the replay mechanism would be solving a problem the protocol has already removed.

Why the others are wrong — There is no history to replay. Retrying is the client's job rather than something that happens by itself. And the client owns the process, so no reconfiguration is involved.

Remember this — Restart, retry, carry on. The absence of session state is what makes a crash uninteresting, and it is worth checking for that property before building recovery machinery in any protocol.

Sources — MCP first-party documentation.

Sources

Primary sourcestdio — MCP · accessed 20 Aug 2026
“If the server process exits unexpectedly, the client SHOULD restart it.”
Primary sourcestdio — MCP · accessed 20 Aug 2026
“Because the protocol is stateless, any in-flight requests are simply lost and the client can retry them against the fresh process.”

Practise 10 questions on this topic

Take MCP Fundamentals — Timed Test 1 (10 questions) — scored instantly, explanation for every question, no login.

Start the test

A stdio server crashes mid-session with two tool calls outstanding. A developer starts designing a mechanism to replay session state into the replacement process. Is that mechanism needed?

Mediummcpstatelessstdioreliability

Last reviewed 22 Aug 2026

No, and nothing needs retrying either, because the client resumes the outstanding calls automatically after a restart.
Yes — the new process has to be brought up to the point the old one reached before it can serve anything.
No, but the user has to reconfigure the server, since a crashed subprocess cannot be brought back by the client.
No — the protocol is stateless, so the outstanding requests are lost and can simply be retried.Correct answer

Show answer & explanation

Correct answer: D. No — the protocol is stateless, so the outstanding requests are lost and can simply be retried.

Explanation

The principle — Statelessness is not an abstract property; it is the reason a crash is cheap.

Sources — MCP first-party documentation.

Sources

Primary sourcestdio — MCP · accessed 20 Aug 2026
“If the server process exits unexpectedly, the client SHOULD restart it.”
Primary sourcestdio — MCP · accessed 20 Aug 2026
“Because the protocol is stateless, any in-flight requests are simply lost and the client can retry them against the fresh process.”

Practise 10 questions on this topic

Take MCP Fundamentals — Timed Test 1 (10 questions) — scored instantly, explanation for every question, no login.

Start the test

A stdio server crashes mid-session with two tool calls outstanding. A developer starts designing a mechanism to replay session state into the replacement process. Is that mechanism needed?

Related questions

A stdio server crashes mid-session with two tool calls outstanding. A developer starts designing a mechanism to replay session state into the replacement process. Is that mechanism needed?

Related questions