Skip to content

Conversation

cliffhall
Copy link
Member

@cliffhall cliffhall commented Aug 12, 2025

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

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.

Screenshot 2025-08-12 at 3 42 05 PM Screenshot 2025-08-12 at 2 03 36 PM

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

* In useConnection.ts
  - During initialization, if there is an error immediately following the client sending 'logging/setLevel', pops up a toast with the message `Server declares logging capability but doesn't implement method "logging/setLevel"`
* In useConnection.ts
  - During initialization, if there is an error immediately following the client sending 'logging/setLevel', pops up a toast with the message `Server declares logging capability but doesn't implement method "logging/setLevel"`
@cliffhall cliffhall requested a review from olaservo August 12, 2025 19:48
@antholeole
Copy link

thank you for the fix! I agree this is much better than reverting the PR

Copy link
Member

@olaservo olaservo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, looks good to me.

@olaservo olaservo merged commit e36f880 into modelcontextprotocol:main Aug 12, 2025
5 checks passed
@cliffhall cliffhall deleted the add-toast-for-misconfigured-logging branch August 18, 2025 17:29
@cliffhall
Copy link
Member Author

Just tagging a PR I made in the Typescript SDK which adds automatic log level handling to the Server and McpServer classes. If you're getting this toast and wondering how to implement log level handling, don't worry, it should be available soon by just using [Server|McpServer].sendLoggingMessage

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Breaking change in v0.16.3: Automatic setLoggingLevel call fails for servers with incomplete logging implementation
3 participants