Latest Results
refactor(langchain)!: build `langchain.mcp` sessions on the SDK client
`create_session` opened transports by hand, wrapped them in a `ClientSession`, and
described servers with connection types declared here. All three now come from the
SDK: it builds an `mcp.Client` and yields its session, and servers are described by
the SDK's own `ServerParameters`.
`StdioConnection`, `SSEConnection`, `StreamableHttpConnection`, and
`McpHttpClientFactory` are removed. Their fields were a re-declaration of
`StdioServerParameters`, `SseServerParameters`, and `StreamableHttpParameters`, so
mapping configs are now validated by those models instead. The mapping form is
unchanged for callers: the same keys parse into the SDK's models, which ignore the
ones they do not declare, so `auth`, `http_client`, and client options such as
`mode` still ride alongside.
A connection is now one of:
- The SDK's `ServerParameters`.
- A mapping of the same fields, with `transport` selecting the model or inferred
from `command` or `url`.
- A callable returning a transport or a `Client`, for anything the first two cannot
express. It must be a callable rather than an instance, because a session is
opened per operation and both are single-use.
Other consequences:
- The three per-transport session factories are gone.
- Dropping `McpHttpClientFactory` removes a protocol declared over `httpx` types
that this package cannot keep correct, which is what made the `httpx`/`httpx2`
split a silent runtime failure rather than a type error.
- The explicit `initialize` calls are removed, because the client negotiates when
it is entered. They were also fatal against a server on the current protocol
revision, which does not accept the handshake.
- `MultiServerMCPClient.session` no longer takes `auto_initialize`. The session is
always negotiated on connect, so the parameter had nothing left to control.
- Server-initiated features such as elicitation and progress notifications require
`"mode": "legacy"`: the current era's per-request transport has no back-channel
for them, and the elicitation and callback tests pin it for that reason.sydney-runkle/langchain/mcp-client-transports refactor(langchain)!: build `langchain.mcp` sessions on the SDK client
`create_session` opened transports by hand and wrapped them in a `ClientSession`,
which meant this package owned transport construction, HTTP client construction,
and the handshake. It now builds an `mcp.Client` and yields its session, so all
three belong to the SDK.
A connection can now be described three ways, in increasing order of control:
- One of this package's mappings, which describe the server and the HTTP client to
build for it, and so carry `auth`, `http_client`, `headers`, and `timeout`.
- The SDK's own `ServerParameters` — `StdioServerParameters`,
`SseServerParameters`, or `StreamableHttpParameters`. These describe only the
server and a few HTTP settings; they have no `auth` or `http_client`, which is
why the mappings remain.
- A transport the caller built. This is where the two layers meet: pass
`streamable_http_client(url, http_client=...)` to combine an endpoint with a
fully configured HTTP client, including OAuth or a shared connection pool.
Other consequences:
- The three per-transport session factories are gone, along with roughly a third
of the module.
- `McpHttpClientFactory` is removed. It declared a protocol over `httpx` types
that this package cannot keep correct, which is what made the `httpx`/`httpx2`
split a silent runtime failure rather than a type error. Streamable HTTP takes
an `http_client` instead.
- The explicit `initialize` calls are removed, because the client negotiates when
it is entered. They were also fatal against a server on the current protocol
revision, which does not accept the handshake.
- `MultiServerMCPClient.session` no longer takes `auto_initialize`. The session is
always negotiated on connect, so the parameter had nothing left to control.
- `mode` is now a documented connection option. Server-initiated features such as
elicitation and progress notifications currently require `"legacy"`: the
current era's per-request transport has no back-channel for them, and the
elicitation and callback tests pin it for that reason.sydney-runkle/langchain/mcp-client-transports refactor(langchain)!: build `langchain.mcp` sessions on the SDK client
`create_session` opened transports by hand and wrapped them in a `ClientSession`,
which meant this package owned transport construction, HTTP client construction,
and the handshake. It now builds an `mcp.Client` and yields its session, so all
three belong to the SDK.
A connection can now be described three ways, in increasing order of control:
- One of this package's mappings, which describe the server and the HTTP client to
build for it, and so carry `auth`, `http_client`, `headers`, and `timeout`.
- The SDK's own `ServerParameters` — `StdioServerParameters`,
`SseServerParameters`, or `StreamableHttpParameters`. These describe only the
server and a few HTTP settings; they have no `auth` or `http_client`, which is
why the mappings remain.
- A transport the caller built. This is where the two layers meet: pass
`streamable_http_client(url, http_client=...)` to combine an endpoint with a
fully configured HTTP client, including OAuth or a shared connection pool.
Other consequences:
- The three per-transport session factories are gone, along with roughly a third
of the module.
- `McpHttpClientFactory` is removed. It declared a protocol over `httpx` types
that this package cannot keep correct, which is what made the `httpx`/`httpx2`
split a silent runtime failure rather than a type error. Streamable HTTP takes
an `http_client` instead.
- The explicit `initialize` calls are removed, because the client negotiates when
it is entered. They were also fatal against a server on the current protocol
revision, which does not accept the handshake.
- `MultiServerMCPClient.session` no longer takes `auto_initialize`. The session is
always negotiated on connect, so the parameter had nothing left to control.
- `mode` is now a documented connection option. Server-initiated features such as
elicitation and progress notifications currently require `"legacy"`: the
current era's per-request transport has no back-channel for them, and the
elicitation and callback tests pin it for that reason.sydney-runkle/langchain/mcp-client-transports Latest Branches
0%
release/langchain_v1-1.3.17 0%
hwchase17/langchain/hitl-reject-framing 0%
sydney-runkle/langchain/mcp-hold-connections © 2026 CodSpeed Technology