What it does
The `logging/setLevel` method is a client-initiated request that instructs the server to adjust its log emission threshold. When the client sends this request with a `level` parameter (one of the standard syslog-style severities: debug, info, notice, warning, error, critical, alert, emergency), the server updates its internal filter and acknowledges with an empty result object. From that point forward, the server suppresses any `notifications/message` log events whose severity falls below the requested level, effectively letting the client control the verbosity of the log stream without restarting the connection. The full request/response cycle is synchronous from the client's perspective: the client sends a standard JSON-RPC request with an `id`, the server processes the level change atomically, and returns `{}` as the result. There is no pagination, no cursor, and no streaming involved. Capability gating is required — both the client and server must have negotiated the `logging` capability during the `initialize` handshake. If the server did not advertise `logging` in its capabilities, the client must not send this request; doing so will yield a `-32601` (method not found) error. Timing matters when log events are in flight. A server may emit a burst of notifications before it processes a `logging/setLevel` request that arrived concurrently, so clients should expect a brief window of out-of-level messages after the request is sent. The server's acknowledged response is the reliable signal that the new threshold is active. Changing the level multiple times in quick succession is safe — each acknowledged response guarantees the server has applied that specific level at that point in time.
When to use
Whenever the user changes verbosity (debug for troubleshooting, error for production).
When NOT to use
On every connection — pick a sane default and let users override.
Notes
Capability gating is mandatory
The server must have advertised `{"logging": {}}` in its `capabilities` field during the `initialize` response before the client sends `logging/setLevel`. If the capability is absent and the client sends the request anyway, expect a `-32601` Method Not Found error. Always guard calls with a capability check rather than relying on error handling at runtime.
Valid level values are syslog-ordered
The `level` parameter must be one of the eight string values defined in the MCP spec: `debug`, `info`, `notice`, `warning`, `error`, `critical`, `alert`, `emergency`, in ascending severity order. Sending an unrecognized string will produce a `-32602` Invalid Params error. The server filters out notifications strictly below the requested level, so setting `warning` suppresses `debug`, `info`, and `notice` events but passes through `warning` and above.
Race window after acknowledgment
Because notification dispatch and request processing run on the same transport stream, the server may have already queued log notifications before it processes the `setLevel` request. Clients should handle a brief burst of below-threshold messages arriving after the acknowledged response and not treat them as a server bug. Idempotent log consumers that filter by level client-side are the most resilient pattern.
No persistence across sessions
The log level is session-scoped and resets to the server's default (typically `info` or `warning`) on every new connection. Clients that need a consistent verbosity must re-send `logging/setLevel` immediately after the `initialize` handshake completes and before issuing any other requests, to avoid missing early log events.
SDK default behavior varies
Several MCP SDK implementations (TypeScript, Python) default to not calling `logging/setLevel` at all, leaving the server at its compiled-in default level. If you are building a client and want verbose debug output during development, explicitly send `logging/setLevel` with `level: "debug"` right after capability negotiation. Conversely, production clients should set `warning` or higher to avoid log-notification overhead on high-throughput transports like stdio.
Request parameters
| Name | Type | Purpose |
|---|---|---|
| level | LoggingLevel | Minimum severity. |
Examples
Set warning
{ "method": "logging/setLevel", "params": { "level": "warning" } }Common mistakes
❌ Ignoring the setting
✅ Servers MUST honour it.