User should set RootsListChanged capability

[lorenzocesconetto]

SDK user will set whether it supports RootsListChanged.
To fall into the safe side, the capability defaults to False.

Motivation and Context

I was thinking of a more robust solution for this, but since it's the user providing the callback, I don't think there's much we can do here.

How Has This Been Tested?

Locally.

Breaking Changes

No. I added a new arg, but it's in the end of the args list and has a default value.

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

[lorenzocesconetto]

@ihrpr this is a follow up from #802

[hesreallyhim]

yup lgtm 👍

this could be a separate PR, but it might be nice to support "good" default callbacks as well, like if most users want to respond to "roots/list" with a paginated result of roots in some default way, we might consider providing such a facility. Same with roots/listChanged - if I want to support "listChanged" but am happy with some default response, why make each user write their own callback?

EDIT: Irrelevant edit removed.

[lorenzocesconetto]

@hesreallyhim yeah, agreed... I was thinking about implementing something nicer than this simple PR.

A suggestion could be:

• The session takes an optional list of roots as an argument.
• SDK implements a simple default callback that returns the list of roots upon request (user doesn't need to write his own callback).
• Session implements an add_root method that automatically sends a RootsListChanged notification to the connected MCP server (this would be super nice, users would get RootsListChanged support for free).

I can implement this if @ihrpr or @Kludex are on-board (will wait for their blessing, I don't want to waste time implementing it if the core maintainers don't agree).

[felixweinberger]

The core proposal seems right to me - this allows us to more closely align SDKs with the protocol definition.

listChanged indicates whether the client will emit notifications when the list of roots changes.

Right now we're essentially assuming if _list_roots_callback is provided, listChanged=True. This PR allows splitting the existence of the capability from whether we'll actually send notifications (which aren't the same thing).

However, this seems like it could be a breaking change for use cases that are currently relying on the assumed listChanged=True + it now requires users to remember to update 2 places. Adding a default list_changed callback also seems like a potentially good idea but I think unrelated to this PR.

I'm going to request changes for now as we'll also want tests and a sync with main, but I'll mark this for review amongst maintainers and bring it up to the group. I'll come back with feedback as soon as I have it.

[felixweinberger]

Hi @lorenzocesconetto thanks again for this submission - discussed this separately with @dsp-ant and we think this is a sensible change to improve protocol compliance.

However, ideally we'd not have separate parameters for list_roots_callback and support_roots_list_changed - with the current setup it's possible to supply one but not the other for example.

It'd be great if instead of just accepting list_roots_callback on ClientSession here we could accept a struct that requires users to provide the information at the same time, e.g.

@dataclass 
class RootsConfig:
    callback: ListRootsFnT
    list_changed: bool

This would allow us to avoid callback without list_changed being true or vice versa.

Would you have bandwidth / interest in working on this?

[lorenzocesconetto]

Hi @felixweinberger
Yeah, let me take a look over the weekend.
Thanks for providing feedback.

[felixweinberger]

Converting this to a draft while we await changes discussed above to remove it from the review queue for now.