Description

• In useConnection.ts
  • During initialization, if there is an error immediately following the client sending logging/setLevel, pop up a toast with the message Server declares logging capability but doesn't implement method "logging/setLevel"

Motivation

• Unknown connection regression #699 reported an "unknown regression" when connecting to a server. The problem was diagnosed by @KKonstantinov as stemming from initalize logging after connection #611 which sends a logging/setLevel message during initialization if the server advertises support for the logging capability.
• This issue was also reported in Breaking change in v0.16.3: Automatic setLoggingLevel call fails for servers with incomplete logging implementation #696.

Context

The MCP spec for logging states two relevant things:

Servers that emit log message notifications MUST declare the logging capability:

{
"capabilities": {
   "logging": {}
 }
}

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

{
 "jsonrpc": "2.0",
 "id": 1,
 "method": "logging/setLevel",
 "params": {
   "level": "info"
 }
}

The Inspector is clearly operating in spec. A server that advertises that it supports logging but actually doesn't is operating out of spec.

Other clients in the wild which follow spec will naturally do this and when it fails with them, it's more likely a real "getting in the way of work" problem.

If we revert the automatic setLevel request, we're only encouraging server developers to continue doing the wrong thing. This is after all, a tool for developers to inspect their servers and determine if they're operating correctly.

But clearly a failure to connect with no clear feedback as to why is a poor user experience and doesn't help the developer to diagnose and fix the problem. So we opted to add a toast message when a Method Not Found error is thrown as a result of sending the logging/setLevel request.

How Has This Been Tested?

Commented out the request handler for SetLevelRequestSchema in the server-everything reference server, which declares support for the logging capability during the initialization.

Breaking Changes

Nope.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

This closes #696 & #699