MCP logging is the protocol’s channel for a server to send free-text diagnostic messages back to the client while it runs — debug lines, a warning about a slow upstream call, a note that a cache missed. It has nothing to do with the audit trail of which tools got called with what arguments, and nothing to do with whether a tool call succeeded. It’s one of the oldest, least-discussed utilities in the spec, which is partly why so few servers bother to implement it.

How the mechanism works

A server that wants to use this declares a logging capability during initialization, the same way it declares support for tools, resources, or prompts. Once that’s in place, the client can send a logging/setLevel request naming a minimum severity it wants to receive — anything below that threshold, the server shouldn’t bother sending. The levels follow the familiar syslog scale: debug, info, notice, warning, error, critical, alert, and emergency, in that order.

From there, the server pushes notifications/message whenever it has something to say: a severity level, an optional logger name identifying which part of the server is talking, and a data field carrying the actual message — a string, or any JSON-serializable structure the server finds useful. Like the progress notifications we covered in MCP progress notifications explained, these ride on the existing connection as a side channel. There’s no request this is a reply to, and no response expected back — it’s a one-way stream the client can watch, filter by level, or ignore entirely.

What it isn’t

It’s easy to conflate this with a few other things in MCP that also involve the word “log” or “message,” so it’s worth being specific about what MCP logging is not:

  • It’s not a tool call result. A failed tool call reports failure through isError on its own result object, which we cover in MCP tool error handling. Logging messages are separate chatter that can happen whether or not any particular call succeeds, failed, or is even in flight.
  • It’s not an audit log. The record you’d want for compliance or incident response — which tool was called, by which client, with what arguments, at what time — is a product-level concern a gateway or client has to build on its own, covered in MCP observability and audit logs. MCP’s logging utility is unstructured diagnostic text aimed at whoever’s debugging the server, not a durable, structured record of what an agent did.
  • It’s not progress reporting. notifications/progress is tied to one specific in-flight request via a progressToken and stops once that request finishes. notifications/message isn’t tied to any single request at all; a server can emit one at any time for any reason, including when nothing is currently being called.

Why almost nothing uses it

In practice, most MCP clients people actually use — chat apps like Claude.ai or Cursor’s integration — have no UI built for a raw diagnostic stream, so a server that sends notifications/message is mostly logging into a void. The audience that gets real value from it is a developer running the MCP Inspector against their own server during development, where seeing “cache miss, fetching from origin” or “rate limit backing off 2s” next to the actual request and response traffic is genuinely useful for figuring out why a tool call is slow or behaving oddly. Outside that workflow, it’s a capability most server authors skip, not because it’s hard to implement, but because the client side rarely surfaces it to anyone who’d read it.

If you build a server

It’s worth adding if you expect developers to debug against your server directly, or if you’re building a server where silent failures are a real risk — a warning-level message when a fallback path kicks in costs little and can save someone a confusing debugging session later. It’s not worth building a UI feature around for end users, since almost no client will route it anywhere they’d see it. If you’re generating a server from an existing API with a tool like gate’s MCP server builder, this is another piece an OpenAPI spec says nothing about on its own, the same gap we noted for progress notifications and sampling — it’s a layer you add by hand once the generated tool surface exists, if it’s worth adding at all.

Where gate fits: a logging message is diagnostic text from the server to whoever’s watching the connection, not a record of what the agent did or a tool result the model acts on — so it sits outside the allow/ask/block rules a gateway applies to actual tool calls. What a gateway should still cover is the call itself: gate’s free MCP security scanner checks a server’s tool descriptions before you connect, and every real tool call goes into a plain-language log separate from whatever diagnostic chatter the server happens to emit on the side.

The bottom line

MCP’s logging utility is a narrow, opt-in channel for a server to stream severity- leveled diagnostic text to the client, set up with logging/setLevel and delivered as notifications/message. It’s not a call result, not an audit trail, and not progress tracking — it’s closer to a server talking to itself out loud, useful mainly to whoever’s debugging it directly. See gate’s MCP server directory for what today’s servers actually implement, and how to debug an MCP server with the Inspector for where this channel is actually visible in practice.