@posthog/mcp@0.11.2

0.11.2

Patch Changes

• #4463 b8e5d06 Thanks @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 of params._meta while parsing a request, and puts them on the request envelope. We only read params._meta, which is empty by the time a handler runs, so $mcp_client_name, $mcp_client_version and $mcp_protocol_version went missing on exactly the modern-era traffic that carries them per request rather than at initialize.

  Identity is now resolved field by field through three sources in order: the v2 request envelope, then params._meta, then the server's own getClientVersion() 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 8b5165e Thanks @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/mcp into 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 CallToolResult and ListToolsResult from @modelcontextprotocol/sdk/types.js, so a consumer without the v1 SDK hit TS2307 on an install that otherwise worked — fine at runtime, broken under tsc without skipLibCheck. Those MCP wire shapes are now declared structurally in types.ts too.

  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, so getMoreToolsResult() can still be returned straight from a tool callback. (2026-08-10)