Demo MCP server in Kotlin doesn't work since MCP Inspector 0.16.3

[afaucogney]

I just created a simple MCP server with https://github.com/modelcontextprotocol/kotlin-sdk/
The server is working, when started I can push some json et get back response from it.
MCP Inspector is working from version 0.8.0 (maybe also before) until 0.16.2.
But starting by version 0.16.3, I got :

• in the MCP Inspector UI
  => Connection Error - Check if your MCP server is running and proxy token is correct

• in the logs (cli where I start MCP inspector)
  => Created server transport
  => Created client transport
  => Received POST message for sessionId 101bdb7b-e733-4727-94ac-87da74747c1a
  => Received POST message for sessionId 101bdb7b-e733-4727-94ac-87da74747c1a
  => Received POST message for sessionId 101bdb7b-e733-4727-94ac-87da74747c1a (on more line than previous working versions)

in 0.16.6 I also get a graphical notification :

• Error : Server declares logging capabilities but doesn't implement method "logging/setLevel"

[cliffhall]

Hi @afaucogney!

TL;dr - The spec says that, if a server advertises logging as a capability the client MAY send a logging/setLevel request. If the server does not accept that request, it can cause the initialization process to fail. Not just for the Inspector, but for any client that is following the spec and chooses to send this message immediately after receiving the server capabilities.

How we got here, and what's being done:

1. We previously added a log level dropdown to the Inspector to allow the user to change the log level, but of course client and server must agree on the initial level for the value in that combobox to be correct. Therefore, it also sends the logging/setLevel message to any server that says it supports logging. That is perfectly within spec.

2. We later realized that some servers are operating out-of-spec, advertising support for logging but not listening for this message. And yes, tragically, our examples in the Typescript SDK were all offenders. (This is likely the case with all the other SDKs, something I will be starting a campaign to fix after the next release of the Typescript SDK, see below). The result was that the server would not connect, and it was not clear why. The actual reason was that it was throwing a "Method not found" error since it had no listener for the RPC method logging/setLevel.

3. This is a tool for devs to make sure their servers are operating properly, so not sending the message and letting out-of spec behavior slide was not the right course of action. Consequently, I added a change that detected the situation and explained the problem with a toast.

4. That left us in a position where a) our examples had problems and triggered this toast, and b) all server developers who advertised logging in their servers would have to implement the same boilerplate code we already had in our 'Everything' reference server in order to interact with any client that chooses to send the logging/setLevel message.

5. I added automatic log level handling to the Typescript SDK and fixed all the examples. I also updated the Everything reference server, removing its boilerplate handling and using this functionality. In doing that, I realized there was no STDIO example in the SDK, and so it had slipped through the cracks. Because the stored level was mapped to session id, which STDIO does not have, it worked for SSE and StreamableHttp but not STDIO. The STDIO server would connect, but messages would not be filtered.

6. Finally, the upcoming release of the Typescript SDK will contain the fix for STDIO, and will provide a full and simple to implement example for other SDK maintainers to follow. The only thing server developers will have to do to avail themselves of the automatic log level handling will be to simply add logging to their capabilities response, and to call sendLoggingMessage with the parameters of the log message, rather than creating the full message and using notification.

[carlodek]

Hello @afaucogney , faced same problem, as a workaround and just to test it, you can set logging =null into ServerCapabilities class like example below:

 val server = Server(
        Implementation(
            name = serverName,
            version = BuildInfo.VERSION//You need to build before to get this object into build/generated folder
        ),
        ServerOptions(
            capabilities = ServerCapabilities(logging = null, tools = ServerCapabilities.Tools(listChanged = true))
        )
    )