0.11.2
Patch Changes
-
#4463
b8e5d06Thanks @gesh! - Resolve client name, version and protocol version through a fallback chain, so events from an MCP SDK v2 server carry them.MCP SDK v2 lifts the reserved
io.modelcontextprotocol/*keys —clientInfo,protocolVersion,clientCapabilities— out ofparams._metawhile parsing a request, and puts them on the request envelope. We only readparams._meta, which is empty by the time a handler runs, so$mcp_client_name,$mcp_client_versionand$mcp_protocol_versionwent missing on exactly the modern-era traffic that carries them per request rather than atinitialize.Identity is now resolved field by field through three sources in order: the v2 request envelope, then
params._meta, then the server's owngetClientVersion()and (v2-only)getNegotiatedProtocolVersion(). A chain rather than a branch, because the same v2 server serves 2025-era requests routinely — era is a per-request property, never a module constant — and because a field one source cannot answer may still be known to the next. (2026-08-10) -
#4464
8b5165eThanks @gesh! - Install and type-check cleanly on a project that has only MCP SDK v2.@modelcontextprotocol/sdk(v1) was a required peer, so installing@posthog/mcpinto a project built on@modelcontextprotocol/server(v2) pulled the entire v1 SDK in as an auto-installed peer — 87 packages where 1 was wanted — and tooling that walks the dependency tree reported it as missing when it was absent. Both majors are now declared and both are optional, which is what the code has always assumed: no@modelcontextprotocol/*package is imported at runtime, and server shapes are detected structurally.Making the peer optional exposed a second half of the same problem. The published type declarations still imported
CallToolResultandListToolsResultfrom@modelcontextprotocol/sdk/types.js, so a consumer without the v1 SDK hitTS2307on an install that otherwise worked — fine at runtime, broken undertscwithoutskipLibCheck. Those MCP wire shapes are now declared structurally intypes.tstoo.The shapes we read are open-ended, so a value typed by either SDK assigns to them. What the package hands back is typed precisely and stays assignable to the SDK's own
CallToolResult, sogetMoreToolsResult()can still be returned straight from a tool callback. (2026-08-10)