feat(client): return empty lists when server lacks capability #1386
+113
−3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
🦋 Changeset detectedLatest commit: 51ddff5 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
@modelcontextprotocol/client
@modelcontextprotocol/server
@modelcontextprotocol/express
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
Per the MCP spec, "Both parties SHOULD respect capability negotiation."
Previously, calling listPrompts/listResources/listTools on a server that
didn't advertise those capabilities would still send the request, causing
servers to log warnings and creating unnecessary traffic.
Now the Client respects capability negotiation by default:
- listPrompts() returns { prompts: [] } if server lacks prompts capability
- listResources() returns { resources: [] } if server lacks resources capability
- listResourceTemplates() returns { resourceTemplates: [] } if server lacks resources capability
- listTools() returns { tools: [] } if server lacks tools capability
Each logs a debug message when this occurs for visibility.
The existing enforceStrictCapabilities option is preserved - when set to
true, these methods will still throw errors as before.
Co-Authored-By: Claude Opus 4.5 <[email protected]>
PederHP
force-pushed
the
respect-capability-negotiation-in-list-methods
branch
from
87ed7c6 to
8fcec13
Compare
Co-Authored-By: Claude Opus 4.5 <[email protected]>
These tests were setting up servers with tools capability in the constructor
but then returning empty capabilities in the InitializeRequestSchema handler.
Now that the client respects capability negotiation, listTools() was returning
empty lists since no tools capability was advertised.
Fixed by returning { tools: {} } in the InitializeRequestSchema handlers.
Co-Authored-By: Claude Opus 4.5 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation and Context
Going through logs of an MCP server not advertising prompts during capabilities negotiation, I noticed
listPromptsrequests from a client causing a lot of noise. I was about to create an issue with the client, but on second thought, I think the SDK shouldn't require clients to check capabilities manually before calling list methods. I can't think when it would ever be a good idea to send the request to a server that doesn't advertise the capability, so the SDK should make it easy to call the methods without causing server noise and just get an empty list anyway.Per the MCP spec, "Both parties SHOULD respect capability negotiation." Previously, calling listPrompts/listResources/listTools on a server that didn't advertise those capabilities would still send the request, causing servers to log warnings and creating unnecessary traffic.
Now the Client respects capability negotiation by default:
Each logs a debug message when this occurs for visibility. Let me know if you want this removed - I was unsure whether to add it.
The existing enforceStrictCapabilities option is preserved - when set to true, these methods will still throw errors as before.
Also fixed three subtle test bugs with incorrect capability declaration.
How Has This Been Tested?
Added tests.
Breaking Changes
None
Types of changes
Checklist