[wip] Added functions read_resource and resource_templates from client/session.py to client/session_group.py

[AishwaryaKalloli]

Adding functionalities to client/session_group.py that are present in client/session.py.

Motivation and Context

Saw this issue where the user wants capabilities to broadcast notification to all the connected clients from a server.
Saw a similar implementation on client side at client/session_group.py. Wanted to make all the functions available here first, also helps me understand the how to implement server/session_group.py better.

If this looks good I can add the remaining functions to client session group first then create server session group.

How Has This Been Tested?

Tested through unit tests.

Breaking Changes

No.

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

[felixweinberger]

Hi @AishwaryaKalloli thanks for this contribution! And apologies for the time it took to get back to you on this PR.

Broadcasting list_changed is an interesting use case - normally I would think this is for the server implementation to manage what sessions need to be broadcast to, but I see the potential argument for making this a feature of the SDK that takes care of this for the SDK user.

Probably needs a bit of discussion among the maintainer group - I'm going to request changes for now as there will still be updates required (e.g. testing & a sync with main) but I'll report back here with feedback when I have it.

[felixweinberger]

I'm closing this one for now as this seems like a feature that should be handled at the application layer. This can be implemented by applications that need it - many will not.

As it's our goal for the MCP SDK to be a minimal implementation of the core protocol, we'd rather not take on this maintenance complexity.

If you believe this would be a widely requested feature, it may be worth filing a SEP so that we figure out a standard way of implementing this broadcasting across SDKs.