Auditability & Observability

What to log

An auditable MCP deployment records:

• Tool invocations — which tool, which server, arguments (redacted where sensitive), result status, timestamp, initiating user/request
• Consent decisions — what was approved or denied, by whom, when, and under what policy
• Connection and request lifecycle — server launches/connections, protocol versions, capability sets negotiated or discovered
• Errors — protocol errors, tool execution errors, timeouts, cancellations
• Authorization events — token issuance, scope grants, rejections
• Definition changes — tool/resource/prompt list_changed events (rug-pull detection)

Caution

Log messages themselves are a security surface: the spec says they MUST NOT contain credentials or secrets, personal information, or internal details that could aid an attack. Servers should also rate-limit log emission.

Protocol support for observability

• MCP includes a logging utility: a server that declares the logging capability can emit notifications/message log entries with an optional logger name and arbitrary JSON data
• Log severity levels follow RFC 5424 (syslog): debug, info, notice, warning, error, critical, alert, emergency — 8 levels
• How the client sets verbosity depends on the spec revision: through 2025-11-25 the client sent a logging/setLevel request; in 2026-07-28 that method was removed and the level travels per-request in _meta (io.modelcontextprotocol/logLevel)
• Progress notifications (notifications/progress) give visibility into long-running operations
• ping supported liveness monitoring in revisions through 2025-11-25; it was removed in 2026-07-28
• The 2026-07-28 revision deprecates the logging feature itself — migration guidance is to log to stderr (stdio) or use OpenTelemetry
• stdio servers must never write logs to stdout (only valid MCP messages are allowed there — anything else corrupts the protocol stream); the server MAY write UTF-8 logs to stderr, which the client may capture, forward, or ignore

flowchart LR
C[Client / Host] -- "stdin: JSON-RPC only" --> S[stdio Server]
S -- "stdout: JSON-RPC only" --> C
S -. "stderr: logs (capture, forward, or ignore)" .-> C

stdio streams: protocol vs. logs

Observability practices

• Centralize logs from hosts and servers; correlate by request IDs
• Monitor for anomalies: unusual tool-call frequency, unexpected argument patterns, spikes in errors, calls outside business hours
• Alert on high-risk events: destructive tool use, consent bypass attempts, token validation failures
• Retain audit logs per compliance requirements (e.g. SOC 2, GDPR data-access records)

Tip

Auditability is one reason token passthrough is forbidden: if a server forwards tokens it did not issue, downstream logs record the wrong identity and the audit trail breaks. Servers MUST only accept tokens issued for them.

Governance

Server inventory

Maintain an inventory of approved servers: versions, publishers, scopes.

Onboarding policy

Define policies for adding new servers: review, sandbox testing, approval.

Permission reviews

Periodically review granted permissions against actual usage.

Key exam points

• stdio servers log to stderr, never stdout
• MCP’s logging levels follow RFC 5424 (syslog severities), 8 levels from debug to emergency
• Server log entries are sent as notifications/message; verbosity was controlled via logging/setLevel before the stateless 2026-07-28 revision moved it into per-request _meta
• Log content must exclude secrets and personal information
• Auditability requires logging both actions (tool calls) and decisions (consent)

Check your knowledge

📝 Check your knowledge

1. Why must a stdio-based server avoid writing logs to stdout?

Astdout is reserved for the client's messagesBOnly valid MCP JSON-RPC messages may go to stdout; anything else corrupts the protocol streamCstdout is not captured by most operating systemsDThe spec requires all logs to be sent over HTTP

2. Which standard defines the severity levels used by MCP's logging utility?

ARFC 6570BRFC 8707CRFC 5424DRFC 9728

3. Which notification carries a server's log entries to the client?

Anotifications/progressBnotifications/messageCnotifications/tools/list_changedDnotifications/cancelled

4. What does the MCP spec say about log message content?

ALogs should include full request payloads for traceabilityBLogs must not contain credentials, secrets, or personal informationCLogs must always be encrypted at restDLogs must be written in plain English

5. Why does token passthrough undermine auditability?

AIt makes tokens expire fasterBDownstream audit logs record the wrong identity, breaking accountabilityCIt disables the logging capabilityDIt forces logs onto stdout

6. Why is monitoring list_changed events an audit practice?

AIt measures server latencyBIt detects rug-pull attacks where a server silently changes its tool definitionsCIt is required to keep the connection aliveDIt replaces consent logging