Skip to content

Reject listRoots when roots capability is unsupported - #1144

Open
zsewasdsdsd wants to merge 1 commit into
modelcontextprotocol:mainfrom
zsewasdsdsd:feature/list-roots-capability-check
Open

zsewasdsdsd wants to merge 1 commit into
modelcontextprotocol:mainfrom
zsewasdsdsd:feature/list-roots-capability-check

Conversation

@zsewasdsdsd

Copy link
Copy Markdown

Reject listRoots early when the client has not initialized capabilities or does not advertise the roots capability, instead of sending an unsupported roots/list request.

Motivation and Context

Fixes #1067.

Other server-to-client operations already fail fast when the client does not advertise the required capability. McpAsyncServerExchange.listRoots(...) did not perform the equivalent check and could send a roots/list request to a client that does not support roots.

This change adds the missing capability validation and preserves the existing "Roots not supported" error behavior.

How Has This Been Tested?

Added regression coverage for:

  • calling listRoots before client capabilities are initialized
  • calling listRoots when the client does not advertise the roots capability
  • verifying that no roots/list request is sent when either capability check fails

Targeted core tests pass locally:

McpAsyncServerExchangeTests
Tests run: 38, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS

The existing roots capability integration tests were also verified successfully:

HttpServletStreamableIntegrationTests.testRootsWithoutCapability
PASS

HttpServletSseIntegrationTests.testRootsWithoutCapability
PASS

A full local test run still encounters two unrelated SSE/tool timeout failures:

HttpServletSseIntegrationTests.testToolListChangeHandlingSuccess
HttpServletSseIntegrationTests.testToolCallSuccess

Both failures were reproduced on a clean upstream/main worktree, so they are not introduced by this change.

Breaking Changes

No.

The change only adds fail-fast validation for an operation that requires the client to advertise the roots capability. Supported clients continue through the existing request path unchanged.

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](https://modelcontextprotocol.io)
  • 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

The implementation follows the existing capability-checking pattern used by other server-to-client operations.

The production change is limited to McpAsyncServerExchange.listRoots(...), with corresponding regression tests in McpAsyncServerExchangeTests.

No documentation changes are required because this fixes SDK behavior to enforce the existing client capability contract.

@zsewasdsdsd

Copy link
Copy Markdown
Author

I noticed after opening this PR that #1105 and #1137 also address #1067.
One compatibility difference is that this PR preserves the existing Roots not supported error behavior. I verified this against both HttpServletStreamableIntegrationTests.testRootsWithoutCapability and HttpServletSseIntegrationTests.testRootsWithoutCapability.
This version also directly exercises the listRoots(String cursor) overload in the missing-roots regression test and keeps the change limited to the implementation and its tests.
Happy to defer to the maintainers on which implementation to keep.

This branch has not been deployed

No deployments
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.

Reject listRoots if not supported by client, without sending any request

1 participant