A team is building a new stdio MCP server for revision 2026-07-28 and wants structured operational logs and telemetry. Which approach matches the specification's current guidance?
Select an answer to reveal the explanation.
Short Explanation
The protocol's built-in logging just got its retirement notice, so you don't build a new house on it. For stdio you write logs to stderr, and for structured telemetry you reach for OpenTelemetry. Stdout stays sacred — only MCP messages go there.
Full Explanation
Revision 2026-07-28 deprecates the Logging feature under SEP-2577: new implementations SHOULD NOT adopt it, and existing implementations SHOULD migrate to logging to stderr for stdio transports or to OpenTelemetry for structured observability. The deprecated feature remains in the specification for at least twelve months, but a new server has no reason to start on it. The stdio transport allows a server to write UTF-8 strings to stderr for any logging purpose, and hosts commonly capture that output. Emitting notifications/message on every request is wrong on two counts: the feature is deprecated, and a server MUST NOT emit those notifications for a request that did not set io.modelcontextprotocol/logLevel in _meta. logging/setLevel was removed; verbosity is now chosen per request, not once per server lifetime. Printing log lines to stdout breaks the transport, because the server MUST NOT write anything to stdout that is not a valid MCP message, and a client parsing stdout will fail on stray text. Exam caveat: Streamable HTTP servers have no stderr channel to the client, so they rely on their own log aggregation or OpenTelemetry. Operational check: run the server under a host, confirm logs appear in the host's captured stderr and spans arrive in the tracing backend, and confirm stdout contains only JSON-RPC lines.