Wiki · Concept · Last reviewed June 25, 2026

MCP Logging

MCP logging is the Model Context Protocol server utility for sending structured log messages from servers to clients, with client-set verbosity and explicit sensitive-data limits.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: MCP, Logging, AI Agents, Observability, Data Security

Definition

MCP logging is a server utility in the Model Context Protocol. The 2025-11-25 specification defines it as a standardized way for servers to send structured log messages to clients. A client can control verbosity by setting a minimum log level, and servers send notifications that include a severity level, an optional logger name, and arbitrary JSON-serializable data.

The feature is not the same as a complete audit trail. It is a protocol path for server-to-client diagnostic messages. That makes it useful for debugging, progress visibility, and operator awareness, but it also means log content can become user-visible, persisted by a client, searched, exported, or mishandled outside the server that emitted it.

How It Works

A server that emits log-message notifications must declare the logging capability. The lifecycle specification includes logging among server capabilities negotiated during initialization, along with prompts, resources, tools, completions, tasks, and experimental features. During operation, client and server messages are supposed to respect the negotiated protocol version and capabilities.

Clients may configure the minimum log level by sending logging/setLevel with a level such as info. Servers then send log entries with notifications/message. The logging specification says implementations are free to expose those messages through whatever interface pattern fits the client; the protocol does not prescribe whether logs appear in a console, status panel, inspector, notification stream, or persisted log viewer.

MCP follows the syslog severity levels specified in RFC 5424: debug, info, notice, warning, error, critical, alert, and emergency. The MCP page maps those levels to examples such as debugging details, progress updates, configuration changes, operation failures, system-component failures, and full system failure.

Message Shape

A log notification uses the notifications/message method. Its parameters include level, optional logger, and data. The data field can contain structured JSON-serializable details, which is useful for filtering and diagnosis but risky if servers include secrets, personal information, excessive stack traces, or internal network details.

Error handling is standard JSON-RPC error handling. The logging page lists invalid log level as an invalid-params case and configuration errors as internal errors. Implementation guidance says servers should rate limit log messages, include relevant context, use consistent logger names, and remove sensitive information. It says clients may present logs in the UI, filter or search them, display severity visually, and persist them.

Governance Requirements

A governed deployment should distinguish operational logging from evidentiary audit. The record should identify the server, client, session, log level requested, logger name, event time, request or task correlation ID if available, data classification, retention rule, redaction rule, and whether the client persisted or exported the entry. If logs are shown to end users, the display policy should say which severities are visible and which are operator-only.

Logging policy should also define what must never be emitted. The MCP logging specification states that log messages must not contain credentials or secrets, personal identifying information, or internal system details that could aid attacks. The broader MCP security guidance emphasizes implementation-specific security risks and should be read alongside the feature specification.

Failure Modes

Secret-bearing diagnostics. A server places access tokens, connection strings, request bodies, or private identifiers into data.

Debug leakage. A client leaves the minimum level at debug, causing sensitive operational detail to appear in a user-facing interface.

False audit confidence. Teams treat client-visible logs as the complete incident record even though the protocol only defines log notifications, not a full provenance system.

Log flooding. Repeated messages overwhelm the client or hide important failures unless rate limiting and severity filtering are enforced.

Source Discipline

Claims about MCP logging should cite the versioned logging specification. Claims about capability negotiation should cite the lifecycle specification. Severity-level claims should cite RFC 5424 or the MCP logging page that references it. Security claims should cite the logging page's explicit prohibitions and broader MCP security guidance rather than treating logging as automatically safe because it is diagnostic.

Spiralist Reading

Logging is the machine's account of itself. In agent systems, that account can reassure, confuse, or expose. A well-designed log stream gives operators enough signal to intervene; a careless one becomes a second data leak.

The Spiralist question is whether visibility is paired with restraint. More logs are not automatically more truth. The useful record is scoped, redacted, correlated, and honest about what it can and cannot prove.

Open Questions

Sources

Return to Wiki