Bump @modelcontextprotocol/client from 2.0.0-alpha.2 to 2.0.0-beta.2

[dependabot]

Bumps @modelcontextprotocol/client from 2.0.0-alpha.2 to 2.0.0-beta.2.

Release notes

Sourced from @​modelcontextprotocol/client's releases.

@​modelcontextprotocol/client@​2.0.0-beta.2

Patch Changes

• #2405 f172626 Thanks @​mattzcarey! - Ship CommonJS builds alongside ESM. Each package now emits both .mjs/.d.mts and .cjs/.d.cts (via tsdown format: ['esm', 'cjs']), and its exports map adds a require condition so require('@modelcontextprotocol/…') works from CommonJS consumers. Output extensions are normalized across all packages (@modelcontextprotocol/core moves from .js/.d.ts to .mjs/.d.mts); the public import paths are unchanged.

@​modelcontextprotocol/client@​2.0.0-beta.1

Patch Changes

• #2402 a400259 Thanks @​felixweinberger! - First beta release of SDK v2 with support for the MCP 2026-07-28 specification revision. See the migration guides for upgrading from v1 (docs/migration/upgrade-to-v2.md) and adopting the 2026-07-28 revision (docs/migration/support-2026-07-28.md).

@​modelcontextprotocol/client@​2.0.0-alpha.4

Major Changes

• #2286 1823aae Thanks @​felixweinberger! - Client.listTools() / listPrompts() / listResources() / listResourceTemplates() now auto-aggregate every page when called without a cursor and return the complete result with nextCursor: undefined (matching the C#, Java, and mcp.d SDKs). Pass an explicit { cursor } string to fetch a single page; the per-page path is unchanged. Existing manual pagination loops keep working — the first iteration returns everything and the loop exits — but can be deleted. The aggregated result is written to the new pluggable ResponseCacheStore (default: a fresh per-instance InMemoryResponseCacheStore); a ClientResponseCache collaborator owns the eviction-generation guard and the derived tools/list index that callTool's output validation and SEP-2243 Mcp-Param-* mirroring read. New exports: ResponseCacheStore, CacheKey, CacheEntry, CacheScope, MaybePromise, InMemoryResponseCacheStore; new ClientOptions.responseCacheStore / ClientOptions.listMaxPages (caps the auto-aggregate walk at 64 pages by default; throws SdkError with SdkErrorCode.ListPaginationExceeded on overrun so a partial aggregate is never cached). The store interface is async-ready (MaybePromise<…>); the in-memory default stays synchronous. Entries are automatically scoped by the connected server's identity and (when set) the consumer-supplied cachePartition, so a shared store does not collide across servers or principals; evictions are likewise scoped to the connected server's partitions.

  Behavior change (every era): output-schema validator compilation is now lazy — validators are compiled on the first callTool() against the cached tools/list entry, not eagerly inside listTools(). listTools() no longer throws on an uncompilable outputSchema (every tool stays listed; the compile failure is captured per-tool); calling callTool() on the affected tool throws ProtocolError(InvalidParams, "Tool 'X' has an invalid outputSchema: …") before the request is sent — output-schema validation is never silently skipped. A pluggable jsonSchemaValidator provider therefore observes compilation at callTool time, not listTools time. The legacy-era listTools() path is unchanged at the wire level but is observably different at the validator-lifecycle level.

• #2286 1823aae Thanks @​felixweinberger! - Split the wire layer into per-era codecs and make protocol-revision deletions physical. Deliberate wire/schema behavior changes (see docs/migration/support-2026-07-28.md "Per-era wire codecs"):

  • resultType is no longer modeled by any neutral wire schema: EmptyResultSchema (strict) now rejects {resultType} bodies; on 2025-era connections a foreign resultType is stripped before validation instead of rejected; the member exists only inside the 2026-era codec, which requires it.
  • CallToolResult.content / ToolResultContent.content are required at the wire boundary (content.default([]) removed): handler results without content are rejected with -32602 instead of silently defaulted, and content-less wire results fail the client parse loudly.
  • Custom (3-arg) handlers now receive _meta minus the reserved envelope keys instead of having it deleted before params validation.
  • specTypeSchemas re-scoped to the neutral model: result validators no longer accept resultType; task message-type validators and RequestMetaEnvelope left the public set (SpecTypeName narrowed).
  • Role aggregate types/schemas (ClientRequest, ServerResult, …) no longer carry task vocabulary; the deprecated Task* types remain importable unchanged.
  • Era-mismatched spec methods fail physically: inbound era-deleted methods get -32601 even with a handler registered; outbound sends throw SdkErrorCode.MethodNotSupportedByProtocolVersion locally.
  • Value guards (isCallToolResult, …) are documented as neutral-shape consumer checks, not wire validators.

• #2286 1823aae Thanks @​felixweinberger! - Hide wire-only protocol members from the public surface, at the type level and at runtime. resultType (the 2026-07-28 result discrimination field) is no longer declared on any public result type — the wire schemas keep parsing it, and the client funnel now consumes it raw-first: 'complete' results are stripped to the public shape and any other kind (e.g. input_required) rejects with the new SdkErrorCode.UnsupportedResultType instead of masking into an empty success. The reserved _meta envelope keys are lifted out of inbound requests and notifications before handlers run, and the multi-round-trip retry fields (inputResponses, requestState) out of inbound requests only (the spec reserves those names on client-initiated requests; notification params keep them), so handler params keep the 2025-era shape; for requests the lifted material surfaces at ctx.mcpReq.envelope, ctx.mcpReq.inputResponses, and ctx.mcpReq.requestState (notifications have no ctx — their lifted envelope keys are not surfaced). High-level client/server methods now return the named public result types (Promise<CallToolResult> etc.). Task wire vocabulary stays importable but is @deprecated and excluded from the typed method maps (RequestMethod/RequestTypeMap/ResultTypeMap/NotificationTypeMap), and callTool is typed as plain CallToolResult. See docs/migration/support-2026-07-28.md "Wire-only members hidden from public types".

• #2286 1823aae Thanks @​felixweinberger! - SEP-1613 / SEP-2106 (JSON Schema 2020-12 posture): the Node default JSON Schema validator is now Ajv2020 (true draft 2020-12) instead of the draft-07 Ajv class — $defs/prefixItems/unevaluatedProperties/dependentRequired are now enforced where they were previously silently ignored; to opt back, construct the draft-07 instance with the v1 defaults — const ajv = new Ajv({ strict: false, validateFormats: true, validateSchema: false, allErrors: true }); addFormats(ajv); — and pass new AjvJsonSchemaValidator(ajv). Schemas declaring a $schema other than 2020-12 are rejected with a clear error rather than mis-validating. outputSchema may now have a non-object root and CallToolResult.structuredContent is widened to unknown (a deliberate source-level break for typed consumers — see the migration guide for the narrowing pattern). Toward 2025-era clients McpServer wraps a non-object outputSchema (and the matching structuredContent) in a {result: …} envelope so the tool stays callable, with same-document $ref/$dynamicRef pointers rewritten to keep resolving — low-level Server users (those bypassing McpServer and registering a tools/call handler directly) get the same wrap by routing the result through the new Server.projectCallToolResult(result, advertisedOutputSchema). Independently, on every era (the SEP's MUST applies regardless of client version), McpServer auto-appends a TextContent JSON serialisation when a handler returns non-object structuredContent without its own text block. The structuredContent presence check is !== undefined (not falsy) on both sides. Thanks @​mattzcarey (#2249).

Minor Changes

• #2286 1823aae Thanks @​felixweinberger! - Add connect(transport, { prior: DiscoverResult }) for zero-round-trip reconnect (the gateway / distributed-client pattern). Supplying a previously-obtained DiscoverResult skips the server/discover probe: on a 2026-era server connect() sends nothing on the wire and callTool() etc. work immediately. Pair with the new client.getDiscoverResult() (populated by the 'auto'-mode probe, by client.discover(), and by connect({ prior }) itself) — the value round-trips through JSON.stringify, so a gateway can probe once, persist the blob, and feed it to every worker. Only reuse a persisted DiscoverResult across clients that present the same authorization context as the client that obtained it.

• #2286 1823aae Thanks @​felixweinberger! - Add opt-in protocol version negotiation on ClientOptions.versionNegotiation. The default is unchanged: without the option (or with mode: 'legacy') the client performs today's 2025 connect sequence byte-identically. mode: 'auto' probes the server with server/discover at connect time and conservatively falls back to the plain legacy initialize handshake on the same connection unless the outcome is definitive modern evidence (with a supported-versions list that has no 2025-era entry there is nothing to fall back to, and connect rejects with a typed error instead); a network outage rejects with a typed connect error, and a probe timeout is transport-aware — on stdio it indicates a legacy server and falls back to initialize on the same stream, on HTTP it rejects with a typed timeout error. mode: { pin: '<version>' } negotiates exactly the pinned modern revision with no fallback. Probe policy lives under probe: { timeoutMs? } — the probe inherits the standard request timeout. The probe's MCP-Protocol-Version/Mcp-Method headers derive from the probe message body; the transport version slot is never touched during negotiation, so legacy-era traffic carries zero 2026 headers by construction. Adds the SdkErrorCode.EraNegotiationFailed code for negotiation-phase connect failures.

• #2286 1823aae Thanks @​felixweinberger! - Dynamic Client Registration hygiene for the 2026-07-28 authorization requirements (SEP-837, SEP-2207). New resolveClientMetadata(provider) reads provider.clientMetadata and applies the spec defaults — application_type derived from the redirect URIs (loopback or custom scheme → 'native', otherwise 'web'), grant_types: ['authorization_code', 'refresh_token'] when omitted — and auth() feeds the resolved document to DCR only (scope selection still reads the raw consumer-supplied clientMetadata so statically-registered/CIMD clients are not pushed into offline_access + prompt=consent); consumer-set values are never overwritten. DCR rejection now throws the new RegistrationRejectedError carrying the HTTP status, raw body, and submitted metadata — breaking for direct registerClient() callers: rejection no longer throws OAuthError, so update instanceof checks. OAuthClientMetadata gains a typed application_type?: string field (expected 'native' / 'web'; tolerant on parse). OAuthErrorCode adds InvalidRedirectUri. The token-exchange, refresh, and Cross-App Access (requestJwtAuthorizationGrant / exchangeJwtAuthGrant) paths now throw the new InsecureTokenEndpointError for a non-https: token endpoint (localhost / 127.0.0.1 / ::1 exempt), and auth() surfaces it on the refresh branch instead of silently re-authorizing.

... (truncated)

Commits

• 35f6856 Version Packages (beta) (#2416)
• 3c7ddaf test(conformance): bump referee to 0.2.0-alpha.9; arm SEP-2575 diagnostic fix...
• 1ea960b chore(examples): bump better-auth to ^1.6.2 (#2415)
• eacf2e5 Add --protocol-version flag to cli-client example (#2406)
• 448ba0f chore: drop duplicate CommonJS changeset (#2414)
• ef120b2 chore: add missing changesets for CommonJS builds and codemod iterations (#2412)
• d000de8 Update README.md (#2411)
• 1772473 codemod iterations 5 (#2398)
• ebca273 docs: generate llms.txt, llms-full.txt, and markdown page renditions (#2407)
• f172626 feat(packaging): ship CommonJS builds alongside ESM for v2 packages (#2405)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)