Refactor notification handling to include all notifications

[nathanArseneau]

This fixes #190

Motivation and Context

Previously, not all notifications were displayed, leading to potential missed updates and crucial information.

How Has This Been Tested?

On any notification

Error warning no impact / change

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

[olaservo]

Thanks for making changes. Did you get a chance to test this after switching to use the specific notification types? For a similar PR we had been using server-everything to simulate the added notifications, so I'm curious how the other types of notifications are being tested. (I'm planning to add more automated testing in the near future since it can be awkward to find the right combination of servers and conditions to test stuff like this manually.)

[cliffhall]

It looks like we may need to add handling for ToolListChangedNotificationSchema and CancelledNotificationSchema to the everything server to test these messages. We could probably find other servers to test this with, but I find none in the official servers project.

[cliffhall]

I previously said

It looks like we may need to add handling for ToolListChangedNotificationSchema, CancelledNotificationSchema to the everything server to test these messages. We could probably find other servers to test this with, but I find none in the official servers project.

But, @olaservo you mentioned automated testing, so I'm not certain putting these in the everything server is the right approach.

Well, we could send periodic ToolListChangedNotificationSchema messages but it would be weird. We wouldn't actually change the tools, it would just prove they could get through to the inspector but also adding noise in the notifications pane.

But it would be useful to make the long running process simulation in the everything server be cancellable. Maybe that's a separate PR since the UI would need to be able to track that long running process id and give you a cancel button while it's running by monitoring progress notifications. What do you think?

[cliffhall]

LGTM! 👍

[seuros]

can we have this merged ?

[olaservo]

Thanks @cliffhall for thinking through the testing approach here. I was tinkering with some sort of integration tests too earlier on which would simulate some of these scenarios.

But it would be useful to make the long running process simulation in the everything server be cancellable. Maybe that's a separate PR since the UI would need to be able to track that long running process id and give you a cancel button while it's running by monitoring progress notifications. What do you think?

Yes agree that seems like something that would be worthwhile for providing a 'live' example of cancelling, as a separate PR.

[cliffhall]

Added an issue to the servers repo for handling cancellation. Will need to add one to this repo as well, for tracking the id and exposing a cancel button.