Skip to content

Conversation

cliffhall
Copy link
Member

@cliffhall cliffhall commented Apr 14, 2025

Description

In everything.ts

  • send a timestamped 'notifications/stderr' message to the client every 10 seconds

Server Details

  • Server: everything
  • Changes to: periodic messages sent to client

Motivation and Context

The everything server is meant to exercise all the MCP features, and is the goto server for testing features in the Inspector.

One of the features we don't exercise is the sending of notifications/stderr messages. They show up in the sidebar, and we had to add special notification handling for that message type in the past.

When a new PR came in to the inspector to add a Clear button for clearing those messages, I had no obvious way to test it.

How Has This Been Tested?

Using the inspector:

Screen.Recording.2025-04-14.at.4.59.19.PM.mov

Breaking Changes

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 Protocol Documentation
  • My changes follows MCP security best practices
  • I have updated the server's README accordingly
  • I have tested this with an LLM client
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have documented all environment variables and configuration options

Additional context

In everything.ts
- add a 10 second interval for sending 'notifications/stderr' messages to the client

This was created in order to test the display and clearing of stderr messages in the client.
- see modelcontextprotocol/inspector#286
@cliffhall cliffhall requested a review from olaservo April 14, 2025 21:23
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.

Should we make this something that can be disabled, in case the user doesn't want notifications firing?

@cliffhall
Copy link
Member Author

cliffhall commented Apr 15, 2025

Should we make this something that can be disabled, in case the user doesn't want notifications firing?

I thought about having an affordance to turn that off in the inspector, but it would mean nothing to any other server you try it with. The everything server is just a good way to see everything in action, so you can look at the code to see "oh, that's how that part works". There isn't anything else to do with it really. We could dial back the frequency to say every 30 seconds or something. It would be enough to reveal the area where error notifications are shown and the clear button that can be used. They don't need to pile up. I'll try that. Come to speak of it, the randomly-leveled log notifications are a little frequent as well.

- subscription updates: 10 seconds
- logging messages: 20 seconds
- stderr messages: 30 seconds
@cliffhall
Copy link
Member Author

Adjusted intervals for outgoing demo messages

  • subscription updates: 10 seconds (was 5)
  • logging messages: 20 seconds (was 10)
  • stderr messages: 30 seconds (was 15)

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.

Looks good to me - I think reducing the frequency is a good compromise here.

@olaservo olaservo merged commit 79542fb into modelcontextprotocol:main Apr 15, 2025
25 checks passed
@cliffhall cliffhall deleted the add-periodic-stderr-messages branch April 15, 2025 15:33
PazerOP referenced this pull request in PazerOP/mcp-template Jul 15, 2025
Add periodic stderr messages and reduce frequency of generated notifcations.
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.

2 participants