What is LoggingLevel?
LoggingLevel is a string enumeration that encodes the severity of a log message emitted by an MCP server. It maps directly onto the eight syslog priority levels defined in RFC 5424, running from the most verbose (debug) through info, notice, warning, error, critical, and alert, up to the most severe (emergency). By reusing an established IETF standard rather than inventing a proprietary scale, MCP makes log output immediately familiar to operators who already work with syslog-compatible infrastructure, journald, or any structured logging pipeline. \n\nIn the MCP message flow, LoggingLevel appears in two places: the notifications/message notification that a server sends to push a log entry to the client, and the logging/setLevel request that a client sends to tell the server the minimum severity it wants to receive. Together these form a lightweight verbosity-control protocol — the server only needs to transmit (and potentially compute) messages at or above the level the client has requested, keeping wire traffic and client-side noise manageable in production deployments. \n\nThe field is a required string enum with no default; the server must always supply an explicit level on every log notification. The closed enum means clients can build exhaustive switch-tables without a catch-all, and servers must not emit values outside the eight defined literals. No numeric alias is defined in the schema, so comparison logic must work with the string values directly. The set has remained stable since MCP 1.0 with no additions planned, as the RFC 5424 vocabulary was chosen precisely because it is unlikely to require extension.
When to use
On every LoggingMessageNotification.
When NOT to use
Never invent custom levels.
Notes
Mapping to host logging frameworks
Most runtimes map syslog levels to their own scale: Python's logging module uses DEBUG/INFO/WARNING/ERROR/CRITICAL and has no notice or alert. When bridging MCP log notifications into a native logger, treat notice as INFO+1 (or a distinct structured field) and alert as CRITICAL+1, otherwise those two levels silently collapse. The Go slog package and Rust tracing crate have the same gap, so write the mapping explicitly rather than relying on a numeric cast.
setLevel is advisory, not enforced
The MCP spec says servers SHOULD respect the client-requested minimum level but does not require enforcement. A server that always emits all levels is technically compliant; the client must still filter. In practice, servers that do heavy diagnostic work inside debug-level code paths should gate that work on the current effective level to avoid CPU overhead even when the client is not listening.
Emergency and alert are rare in practice
The two highest-severity levels — alert and emergency — signal conditions like data corruption or system-wide failure that require immediate human intervention, and most MCP servers will never emit them. Treat their appearance as equivalent to an out-of-band alarm: clients should surface them outside any normal log stream, for example via a dedicated UI banner or an alerting webhook, rather than routing them through the same display path as info messages.
No structured payload on the level field itself
LoggingLevel is a plain string enum; any additional structured context (stack traces, request IDs, custom fields) belongs in the data field of the notifications/message notification, not encoded into the level value. Attempting to embed context by inventing compound values like 'error:timeout' will break clients that do exhaustive enum checks and is explicitly outside the spec.
Ordering is implicit, not schema-enforced
The schema lists the eight literals but does not assign numeric weights or declare an ordering constraint, so JSON Schema validation alone cannot verify that a setLevel request uses a value that is "more severe than" the current level. Servers implementing level-comparison logic must hardcode the RFC 5424 order (debug=7 through emergency=0 in syslog terms) themselves, and should document that ordering in code comments to avoid accidental reversal bugs.
Fields
| Field | Type | Required | Purpose |
|---|---|---|---|
| level | 'debug' | 'info' | 'notice' | 'warning' | 'error' | 'critical' | 'alert' | 'emergency' | yes | Severity. |
Examples
Setting log level
{ "method": "logging/setLevel", "params": { "level": "warning" } }Common mistakes
❌ Logging at debug in production
✅ Respect the client's setLevel — they decide verbosity.