The MCP spec for logging requires a setLevel message before logs should be emitted

[antholeole]

Describe the bug
By default, the UI has the log level set to debug. This doesn't send a "setLevel" message, and so a server implemented to spec will not emit logs.

As a workaround, I setLog to info or higher and then go back to debug to set the correct log level.

Expected behavior
On connection to the MCP server, a setLog level should be sent at debug to initiate logging.

Other Context

Its possible I'm misunderstanding the spec, but the waterfall diagram on the chart is pretty clear that a setLog message should come first

[olaservo]

I think the diagram in the spec is a bit misleading, since the spec also mentions

To configure the minimum log level, clients MAY send a logging/setLevel request:

It mentions that option but its a MAY, so my understanding is that servers can start emitting log messages as soon as the connection is established and capabilities are negotiated, without waiting for a setLevel request. I think the setLevel message is more a way for clients to control the verbosity of the logging, if they want to do that.

[antholeole]

@olaservo

I think what really needs to happen is the spec gets refined - this one seems open to interpretation :) I agree that "sensible" behavior would be what you described, and it's what I had initially thought - but I rethought it because the initial logging level is undefined. A server, imo, shouldn't assume that a client wants debug logs - a sensible default would be e.g. warning, but that would need to be implementation defined since me and you may disagree about it.

Either way I'll address the comments in the PR - thanks for taking a look! Since this is ambiguous and an initial log level is allowed, sending it immediately is probably not a bad solution.

[KKonstantinov]

As per comments left on the PR:

#611

This seems to be breaking the inspector under the following circumstances:

• The MCP Server is registered with the capabilities.logging (most of the @modelcontextprotocol/sdk server examples have that) - example: https://github.com/modelcontextprotocol/typescript-sdk/blob/4d0977bc9169965233120e823c8024e210132ad9/src/examples/server/simpleStreamableHttp.ts#L22-L25
• The MCP server has not registered a requestHandler for the "logging/setLevel" method, and there is no out of the box implementation of such in the @modelcontextprotocol/sdk

The combination of the two above lead to a Method Not Found response from the MCP server.

---

Temporary workarounds (if server in your control)

• Disable the "logging" capabilities of your server
• If you wish to leave them enabled, add a requestHandler to your server like so

server.setRequestHandler(SetLevelRequestSchema, request => {
                        console.log(`--- Logging level: ${request.params.level}`);
                        return {};
                    });

[antholeole]

@KKonstantinov why would the MCP server advertise logging capabilities without actually having logging capabilities? Regardless since this seems to be breaking a lot of people I guess reverting would be the way to go. Sorry about the breakages - it worked under my MCP server!

[KKonstantinov]

@antholeole it's a good question and I agree with you. However the @modelcontextprotocol/sdk examples all advertise logging capabilities without actually having logging capabilities, so my assumption is people are just copying the examples.