Skip to content

Conversation

dwmkerr
Copy link

@dwmkerr dwmkerr commented Jun 7, 2025

Small but explicit addition to the 'stdio' transport that makes it clear that servers may use stderr for all types of logging, including informational, debug and error messages.

Motivation and Context

It is not immediately clear from the specification, and not clear from detailed reading, that the stderr stream for stdio servers can be used not only for errors messages, but for any logging.

The fact that stderr is essentially overloaded to be an output stream for the server is not immediately obvious, as it is a fairly non-conventional approach (although I understand why it has been adopted). This note makes it clear to implementors that it is an accepted pattern to use stderr as a log/output stream, and also to client implementors that they should not assume that messages to stderr actually imply errors (for example, the MCP inspector could use this spec to decide to not show stderr in red, or at least note that the output might not indicate errors).

Logging informational / debug / error messages to stdout has become increasingly conventional in MCP servers but is not inutitive to new adopters, although the pattern has been used in many applications (e.g. the Docker daemon uses stderr for logging as stdout is used for container stdout).

(Evidence)

How Has This Been Tested?

No functional changes.

Breaking Changes

No breaking changes - this already appears to be a common pattter.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

- The server **MAY** write UTF-8 strings to its standard error (`stderr`) for any
logging purposes including informational, debug, and error messages.
- The client **MAY** capture, forward, or ignore the server's `stderr` output
and **SHOULD NOT** assume `stderr` output indicates error conditions.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be tempted to be firmer here and say that clients MUST NOT treat any stderr output as an error condition. Any client doing this is going to cause issues, so I think having it as a hard requirement is warranted so that servers can feel justified and supported by the spec to log to stderr freely.

Suggested change
and **SHOULD NOT** assume `stderr` output indicates error conditions.
and **MUST NOT** assume `stderr` output indicates error conditions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants