Skip to content

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

Description

@michaelboyles

Some requests in McpAsyncServerExchange make a point of failing fast if functionality not supported, such the condition on line 146

public Mono<McpSchema.CreateMessageResult> createMessage(McpSchema.CreateMessageRequest createMessageRequest) {
if (this.clientCapabilities == null) {
return Mono
.error(new IllegalStateException("Client must be initialized. Call the initialize method first!"));
}
if (this.clientCapabilities.sampling() == null) {
return Mono.error(new IllegalStateException("Client must be configured with sampling capabilities"));
}
return this.session.sendRequest(McpSchema.METHOD_SAMPLING_CREATE_MESSAGE, createMessageRequest,
CREATE_MESSAGE_RESULT_TYPE_REF);
}

listRoots does not do the same

public Mono<McpSchema.ListRootsResult> listRoots(String cursor) {
return this.session.sendRequest(McpSchema.METHOD_ROOTS_LIST, new McpSchema.PaginatedRequest(cursor),
LIST_ROOTS_RESULT_TYPE_REF);
}

For example, add this

if (this.clientCapabilities.roots() == null) { 
    return Mono.error(new IllegalStateException("Client must be configured with root listing capabilities")); 
} 

Activity

  1. soyeladice-svg commented on Sep 25, 2026

    @soyeladice-svg

    I reproduced this on current main at c7fef64f92a99c8c758b1aa634f92868d7c2963b.

    A bounded local patch adding the missing initialized-client / roots-capability guard to McpAsyncServerExchange.listRoots(String cursor), plus a regression test asserting that unsupported roots fail before session.sendRequest, passes the project's formatter and focused McpAsyncServerExchangeTests.

    I have not opened a PR yet because CONTRIBUTING asks that non-trivial changes be discussed first. If this scope matches what maintainers want for #1067, I can prepare the focused patch and run the broader required validation before submitting.

    No production access or credentials were involved.

  2. sushma3690 commented on Oct 7, 2026

    @sushma3690

    Hi, I have a fix for McpAsyncServerExchange.listRoots that mirrors the fast-fail capability checks already used by createMessage and createElicitation in the same class. The full mcp-core test suite passes with the change. I noticed PRs are already open for this issue. Before adding a sixth, could a maintainer confirm the desired scope and whether a new PR would help here, or whether you would prefer to pick up one of the existing ones?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Nice to haves, rare edge casesenhancementNew feature or requestgood first issueGood for newcomers

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions