A server team is writing a policy for log messages that may be shown to operators and forwarded to clients. Which content does MCP's logging guidance say log messages must never contain?
Select an answer to reveal the explanation.
Short Explanation
Write every log line as if a stranger will read it, because sooner or later one will. That means no passwords or tokens, no personal details, and no map of your internals for an attacker to study. Logger names, timestamps and correlation IDs are the good stuff you want in there.
Full Explanation
The logging utility's security section states that log messages MUST NOT contain credentials or secrets, personal identifying information, or internal system details that could aid attacks, and that implementations SHOULD rate limit messages, validate data fields, control log access and monitor for sensitive content. The debugging guide repeats the point: sanitize logs, protect credentials and mask personal information. Logger names, severity levels and timestamps are expected content; the logging feature defines RFC 5424 severity levels and an optional logger name, and the debugging guide recommends consistent formats, context and timestamps. Request and correlation IDs are encouraged rather than forbidden, since tracking request IDs is part of a sound logging strategy and scope elevation events should carry correlation IDs. Structured data is allowed; the data field of a log notification may be any JSON-serializable value, and structured logging is the recommended practice. Exam caveat: the protocol-level Logging feature is deprecated in 2026-07-28, but the content rules carry over to stderr and OpenTelemetry pipelines, which can leak secrets just as easily. Operational check: run a scan of recent server logs for token patterns, email addresses and stack traces exposing internal hostnames, and add redaction for anything found.