-
Notifications
You must be signed in to change notification settings - Fork 3k
Support different transports in Client #1972
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Code reviewNo issues found. Checked for bugs and CLAUDE.md compliance. |
Code reviewNo issues found. Checked for bugs and CLAUDE.md compliance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR introduces support for different transports in the Client class, making it more flexible and extensible. The changes enable the Client to work with URL strings, Transport instances, or Server/MCPServer instances, while standardizing the transport interface.
Changes:
- Introduces a
Transportprotocol that standardizes how client transports work - Refactors
Clientclass from manual init to dataclass for better maintainability - Removes the
get_session_idcallback fromstreamable_http_clientto align with Transport protocol (now returns 2-tuple instead of 3-tuple) - Updates
InMemoryTransportto implement the Transport protocol as an async context manager - Updates all tests, examples, and documentation to reflect the 2-tuple return signature
Reviewed changes
Copilot reviewed 25 out of 25 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
src/mcp/client/_transport.py |
New file defining the Transport protocol and TransportStreams type |
src/mcp/client/_memory.py |
Refactored InMemoryTransport to implement Transport protocol via aenter/aexit |
src/mcp/client/client.py |
Converted Client to dataclass, added support for URL strings and Transport instances |
src/mcp/client/streamable_http.py |
Removed get_session_id callback, now returns 2-tuple matching Transport protocol |
src/mcp/client/session_group.py |
Updated to unpack 2-tuple from streamable_http_client |
src/mcp/client/__init__.py |
Added Transport to public exports |
tests/* |
Updated all tests to unpack 2-tuple instead of 3-tuple |
examples/* |
Updated all example clients to use new 2-tuple signature |
docs/migration.md |
Added migration guide for get_session_id callback removal |
README.md, README.v2.md |
Updated code examples to reflect new signature |
.github/actions/conformance/client.py |
Updated conformance tests for new signature |
CLAUDE.md |
Emphasized rule about imports at top of file |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ) | ||
|
|
||
|
|
||
| @dataclass |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious about the motivation for this.
Doesn't this leak _prefixed arguments to the public API? E.g. you could now do:
Client(server, _session=some_session, _exit_stack=some_stack)
And I think it'll also appear in repr() now. Which feels odd / potentially opening up the API for people to do weird stuff that they shouldn't do. Or maybe it's a case of having the _prefix be the message "you're doing weird stuff" and have that be enough?
Not fundamentally opposed - just wondering is the the primary motivation to simplify the class definition here so we avoid self._foo = foo boilerplate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not fundamentally opposed - just wondering is the the primary motivation to simplify the class definition here so we avoid self._foo = foo boilerplate?
Yes. And some other stuff like documenting the parameter close to the definition. And the post_init is focused on the real logic.
felixweinberger
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thanks!
This pull request updates the MCP client codebase to simplify and standardize the transport interface for client-server communication. The main change is that the
streamable_http_clientand related transports now return only a 2-tuple(read_stream, write_stream), removing the previously returnedget_session_idcallback. The documentation and all usage examples have been updated accordingly. Additionally, a newTransportprotocol is introduced to formalize the transport interface, and the in-memory transport is refactored to support async context management. Minor documentation clarifications and type cleanups are also included.Key changes:
Transport Interface Simplification
The
streamable_http_clientnow returns a 2-tuple(read_stream, write_stream)instead of a 3-tuple withget_session_id. All usages in code, examples, and documentation have been updated to match this new interface. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]The
get_session_idcallback is now documented as removed, with migration instructions and alternatives using httpx event hooks provided indocs/migration.md.Transport Protocol and In-Memory Transport Refactor
Introduced a new
Transportprotocol insrc/mcp/client/_transport.pyto standardize the interface for all client transports. [1] [2]Refactored
InMemoryTransportto implement async context management (__aenter__/__aexit__), and updated its usage and documentation for consistency with the new protocol. [1] [2] [3] [4]Documentation and Typing Improvements
Updated
README.v2.md, and all relevant example clients to reflect the new transport interface and provide clear, accurate usage patterns. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]Minor documentation clarifications and type annotation cleanups, including a note in
CLAUDE.mdabout import placement and type signature simplifications. [1] [2]These changes improve consistency, usability, and maintainability of the MCP client transport layer and its documentation.