In MCP, what does the _meta key io.modelcontextprotocol/logLevel control?

## The key `io.modelcontextprotocol/logLevel` is an optional entry in a request's `params._meta`. It tells the server the verbosity at which the client is willing to receive log notifications while that request is handled. The interesting part is the default. The key is optional, but leaving it out is not "use a sensible default level" — it is an instruction. Without it, a server **MUST NOT** emit `notifications/message` for that request. Logging is opt-in per call, and silence is the correct behaviour for a client that never asked. ## What it replaced, and why Before revision 2026-07-28, a client called `logging/setLevel` once and the server remembered the choice for the connection. That is a textbook piece of negotiated per-connection state, and 2026-07-28 removed it along with the handshake, protocol-level sessions and the rest of the machinery that assumed a connection was a conversation. With statelessness as the organising principle, verbosity had nowhere to live but the request, so it moved into `_meta` beside the protocol version and the capability object. The same reasoning explains the strict default. A stateless server has no memory of a client having asked for logs earlier, so an implicit level would mean every server chattering at every client that never opted in. Making absence mean silence keeps the stateless model honest. ## Where the notifications go Log notifications are request-scoped. `notifications/message` travels on the originating request's own response stream — the same channel carrying that request's progress notifications and its eventual result — rather than on a `subscriptions/listen` stream, which exists for opted-in change notifications about the server's tool, prompt and resource sets. That placement follows naturally from the level being a per-request setting: the logs belong to the call that asked for them. ## Deprecated, not just relocated There is a second half to the story that a candidate should volunteer. The Logging feature as a whole was **deprecated** in revision 2026-07-28. Under MCP's deprecation policy a deprecated feature remains in the specification for at least twelve months, new implementations SHOULD NOT adopt it, and the earliest it can be removed is the first revision released on or after 2027-07-28. So it still works, it is still specified, and building something new on it is discouraged. The migration guidance is deliberately unglamorous: - On stdio, **log to `stderr`**. That channel already exists in the transport, is not part of the JSON-RPC stream, and a client SHOULD NOT read output on it as an error signal — it is for diagnostics. - For real observability, use **OpenTelemetry**. This aligns with the tracing keys the protocol already reserves in `_meta`: `traceparent`, `tracestate` and `baggage`, which are the W3C Trace Context exceptions to the usual prefixed-key naming rule. The reasoning is that in-band protocol logging was never a good observability story. It only reaches one client, it only covers requests that opted in, it cannot describe anything happening outside a request, and it duplicates infrastructure every operator already runs. ## How to handle it in practice If you maintain a server that still supports logging, read the key from each request's `_meta`, apply it to that request only, and emit nothing when it is absent. Do not carry a level forward from a previous request — that would be exactly the prior-request inference the revision forbids. If you are writing a server today, the pragmatic path is to send diagnostics to `stderr` on stdio, instrument with OpenTelemetry for anything you actually intend to operate on, and treat protocol logging as a compatibility surface rather than a foundation. ## Why interviewers ask it It is a small, precise probe for whether a candidate knows the current revision or is reciting the handshake era. Naming `logging/setLevel` as the current mechanism dates an answer immediately. A strong answer gives the key, states that absence means silence rather than a default level, and adds that the feature is on a deprecation clock with `stderr` and OpenTelemetry as the destinations.