-
Notifications
You must be signed in to change notification settings - Fork 463
fix: Gate notifications on capabilities #290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Gate notifications on capabilities #290
Conversation
WalkthroughThis change updates the logic in the server session management to ensure that "tools list changed" notifications are only sent when the session is initialized and the server's tool capabilities are both present and enabled. Additionally, a new test verifies that disabling tool capabilities suppresses these notifications while still allowing tool management. Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 golangci-lint (1.64.8)Error: you are using a configuration file for golangci-lint v2 with golangci-lint v1: please use golangci-lint v2 Note ⚡️ AI Code Reviews for VS Code, Cursor, WindsurfCodeRabbit now has a plugin for VS Code, Cursor and Windsurf. This brings AI code reviews directly in the code editor. Each commit is reviewed immediately, finding bugs before the PR is raised. Seamless context handoff to your AI code agent ensures that you can easily incorporate review feedback. Note ⚡️ Faster reviews with cachingCodeRabbit now supports caching for code and dependencies, helping speed up reviews. This means quicker feedback, reduced wait times, and a smoother review experience overall. Cached data is encrypted and stored securely. This feature will be automatically enabled for all accounts on May 16th. To opt out, configure 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall seems good, I left some inline comments. Dealing with the AddTool
/AddSessionTool
without having WithToolCapabilities(...)
been called is probably fine for a follow-up PR though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have been thinking that the SDK should not be opinionated. i.e., even though the spec says:
servers that support tools MUST declare the tools capability.
The SDK allows creating servers with tools WITHOUT mandating declaring this capability. The SDK user still has to manually comply to the spec. I think that is good.
If the SDK is not forcing this, then the SDK should also not prevent sending notifications if this capability is not declared or if it is false.
It should either force users to follow the spec or give proper APIs for people to comply to the spec or not. But it should not be inconsistent.
Maybe checking the official SDKs to see how they do this would help. In either case, we should be consistent IMO.
7c23b66
to
929019a
Compare
@pottekkat that makes sense. This PR doesn't actually prevent users from sending notifications -- it just won't do so automatically after adding or deleting tools. I'll take a peek at the official SDKs and see what they do here. |
Right, it just makes the notifications that we send spec compliant, if the user wants to do notifications on their own we don't prevent it. |
Ya, this makes sense to me. @david-hamilton-glean can you double check what the SDKs do here (before sending a follow-up PR making it an error if you Though I think this PR is still good on it's own (because regardless if the user wants to be spec compliant the sdk itself should be internally). |
929019a
to
5a868e2
Compare
Got it, I haven't gone through the code changes in detail, so maybe I might have misinterpreted the PR description. I can review it tomorrow if we can hold this until then. |
@pottekkat sounds good thanks. I've looked through the typescript SDK. The upshot is I think we should slightly tweak @robert-jackson-glean's original suggestion. When a user adds a tool we should
This is not quite what the typescript-sdk does. They don't really have the server/session distinction that exists in mcp-go. Instead a new server is made per connection and is handed an SSETransport object. When a tool is added via server.tool(), {
tools: {
listChanged: true
}
} This will deep merge and unconditionally set Making tool addition implicitly set If the user has explicitly called |
There was a problem hiding this 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. We can merge this and #292
If the user has explicitly called WithToolCapabilities(false) I don't think mcp-go should implicitly change listChanged though, even though the official ts sdk does this.
This makes sense to me as well. Thank you for checking the official SDKs.
5a868e2
to
cf00332
Compare
@david-hamilton-glean can you also resolve the conflict? |
Servers may report their [tools.listChanged][] capability as false, in which case they indicate that they will not send notifications when available tools change. Honor the spec by not sending notifications/tools/list_changed notifications when capabilities.tools.listChanged is false. [tools.listChanged]: https://modelcontextprotocol.io/specification/2025-03-26/server/tools#capabilities
cf00332
to
1f58f50
Compare
@pottekkat yep was just doing that |
Description
Servers may report their tools.listChanged capability as false, in which case they indicate that they will not send notifications when available tools change.
Honor the spec by not sending notifications/tools/list_changed notifications when capabilities.tools.listChanged is false.
This PR is downstream of #289.
Type of Change
Checklist
MCP Spec Compliance
Additional Information
Summary by CodeRabbit
Bug Fixes
Tests