A host marks a stdio MCP server as failed and restarts it whenever any text appears on the server's stderr, causing constant restarts of a server that logs routine startup messages. What does the stdio specification say?
Select an answer to reveal the explanation.
Short Explanation
Stderr is more like a diary than an alarm bell. Servers jot down all sorts of things there — startup notes, debug chatter and, yes, real errors too. If you restart the server every time it writes a line, you're punishing it for keeping notes.
Full Explanation
The stdio transport specification says the server MAY write UTF-8 strings to stderr for any logging purpose, including informational, debug and error messages, and that the client MAY capture, forward or ignore that output and SHOULD NOT assume stderr output indicates error conditions. A host that restarts a server on any stderr text is therefore misreading a logging channel as a health signal. Claiming stderr is reserved for unrecoverable errors contradicts the explicit permission to write informational and debug output there. Protocol framing lives entirely on stdin and stdout; text on stderr cannot break it, so stderr output says nothing about framing problems. Moving routine messages into notifications/message would push the server onto the Logging feature that 2026-07-28 deprecates, and such notifications may be sent only for requests that set a log level, so startup messages could not use it anyway. Real health signals come from the process exiting unexpectedly, failed responses, or timeouts; the client SHOULD restart a server whose process exits unexpectedly and retry lost requests, since the protocol is stateless. Exam caveat: hosts may surface stderr to users or logs, but should label it as server output rather than an error. Operational check: start the server, confirm routine stderr lines are captured without a restart, then kill the process and confirm the host restarts it.