feat: ClientConnectionManager to manage multiple sessions without async with

[hanhan1123]

This PR introduces a ClientConnectionManager that allows users to manage multiple sessions without needing to explicitly use async with. This provides more flexibility in long-running or dynamic session use cases.
This PR also resolves #922 by allowing users to manage multiple sessions without async with

Motivation and Context

In developing AI agents, the MCP client is often just one part of a larger system. However, the requirement to use async with when initiating sessions makes it difficult to integrate MCP into more complex workflows, especially when other asynchronous components are involved.

To address this, I implemented a ClientConnectionManager that completely removes the need for async with during usage. This provides much greater flexibility in designing and structuring other components, particularly in long-running or modular systems.

How Has This Been Tested?

Code branches are covered via pytest 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

Additional context

[ihrpr]

Thank you for your contribution. The issue mentioned is related to ClientSessionGroup. If there is a specific concern around it, we need to address it in ClientSessionGroup. Adding an additional, very similar abstraction creates API fragmentation and maintenance burden.

[hanhan1123]

@ihrpr
Thank you for the feedback.

Regarding ClientSessionGroup, I’ve evaluated it before proposing this PR. However, it doesn’t fundamentally resolve the session management problem.

ClientSessionGroup still relies on the async with lifecycle, which makes it tricky when you need sessions to persist across a wider application scope. More importantly, it can still hit this error:
RuntimeError: Attempted to exit cancel scope in a different task than it was entered in

And with the current architecture, there’s really no clean way to solve that, because of how async context managers and cancellation scopes work across tasks. That’s why I explored a different approach in this PR.

I’m happy to further discuss how this could evolve to better align with the project’s direction while effectively addressing these session lifecycle constraints.

[qrzeng]

nice, this pr is what i need.