MCP Logging: Status in the Current Spec

Status in the 2026-07-28 spec: deprecated (still functional; eligible for removal in the first spec released on or after 28 July 2027)

The MCP logging utility is a feature that lets a server send structured log messages to the AI app (the client) while it works. Each message has a severity level, an optional logger name and any JSON data.

The 2026-07-28 MCP specification deprecated it. The spec's migration advice is to "log to stderr (stdio) or use OpenTelemetry instead of Logging." It also removed the logging/setLevel method and made log levels a per-request setting. This page covers what still works, what is gone and what to do.

One clarification up front: this page is about the protocol's logging messages. Your own audit logs of who called which tool are a separate and still essential practice. See MCP audit logging.

Why the logging utility existed

When an MCP server misbehaves, developers want to see why. Early MCP gave servers a standard way to stream debug and error messages to the client, which could show them in a console or log panel. It has been in the spec since the first version, 2024-11-05.

Log levels follow the eight syslog severities from RFC 5424: debug, info, notice, warning, error, critical, alert and emergency.

How it works in 2026-07-28

The Logging page of the spec describes the current rules. They are stricter than before.

1. A server that sends log messages declares the logging capability.
2. A client that wants logs for a specific request adds io.modelcontextprotocol/logLevel to that request's _meta, for example "info".
3. The server may then send notifications/message entries at or above that level, on the response stream for that request, before the final response.
4. If the request did not include the field, the server "MUST NOT emit notifications/message."

Log messages are request-scoped. The spec says the server must not deliver them on a subscriptions/listen stream or any other stream. An unrecognized log level should be rejected with JSON-RPC error -32602 (Invalid params).

Here is a log message from the spec:

{
  "jsonrpc": "2.0",
  "method": "notifications/message",
  "params": {
    "level": "error",
    "logger": "database",
    "data": {
      "error": "Connection failed",
      "details": { "host": "localhost", "port": 5432 }
    }
  }
}

What changed across spec versions

In 2025-11-25, a client sent logging/setLevel once and the setting applied for the session. The 2026-07-28 release removed sessions, so a session-wide setting no longer fits. The log level now travels with each request. Read why MCP became stateless for the bigger picture.

The deprecation timeline

The deprecated features registry records:

As with all deprecations under the feature lifecycle policy, the feature stays functional during the window. Core Maintainers decide the actual removal date.

What to use instead

Local servers: stderr

Local servers run over the stdio transport, where stdout carries MCP messages. Write your logs to stderr instead. The stdio transport page says a server "MAY write UTF-8 strings to stderr for any logging purposes," and the client may capture, forward or ignore it. Our guide to the MCP stdio transport explains the split.

Remote servers: OpenTelemetry

OpenTelemetry is an open standard for traces, metrics and logs. It works with most monitoring tools. The 2026-07-28 changelog also documents how to pass OpenTelemetry trace context (traceparent, tracestate, baggage) in _meta. That lets one trace follow a request from the client through the server.

Your own audit trail

Neither of these replaces business audit logs. Record who called which tool, with what arguments and result, in your own systems. MCP governance for IT leaders covers what to keep.

Common mistakes

• Still calling logging/setLevel. It no longer exists in 2026-07-28.
• Sending log messages nobody asked for. Without logLevel in the request's _meta, the server must stay silent.
• Logging secrets. The spec says log messages "MUST NOT contain" credentials, secrets, personal information or internal details that could aid attacks.
• Writing logs to stdout on a stdio server. That corrupts the protocol stream. Use stderr.
• Treating protocol logs as an audit trail. They are optional, client-requested debug output.

Next step

The logging utility often travels with progress updates on the same response stream. Read MCP progress notifications next, or browse the MCP specification reference.

Frequently asked questions