Typescript SDK Updates & Release Notes

Minor Changes

• #2887 edd12e2 Thanks @maxisbey! - Constructing ClientCredentialsProvider, PrivateKeyJwtProvider, StaticPrivateKeyJwtProvider or CrossAppAccessProvider without expectedIssuer is deprecated: the constructor logs one console.warn and that call signature is marked @deprecated. Behaviour is otherwise unchanged. Pass the issuer of the authorization server the credentials were registered with.

  fetchToken() throws AuthorizationServerMismatchError, before sending anything, when the provider's client information is bound to a different authorization server than the one it is called with. The AuthorizationServerMismatchError message no longer assumes the authorization-code callback; its fields are unchanged.

  OAuthTokensSchema and OAuthClientInformationSchema accept the optional issuer stamp, so a provider that reads storage back through them keeps it. auth() overwrites it on every save.

Patch Changes

• #2582 f091897 Thanks @axits-lab! - The v1-to-v2 codemod now writes rewritten imports where the first v1 import stood, not at the top of the file, so a license header, // @ts-nocheck, /// <reference> or a 'use client' / 'use server' / 'use strict' directive above it stays in place. Known gap: when a later step of the codemod replaces or removes the import (for example a file whose only SDK import is ErrorCode or StreamableHTTPError), the new import can still land above or inside the header, and a /** */ header can be removed. Files already migrated with codemod 2.1.0 or earlier are not repaired; check the top of those files.

Minor Changes

• #2887 edd12e2 Thanks @maxisbey! - Constructing ClientCredentialsProvider, PrivateKeyJwtProvider, StaticPrivateKeyJwtProvider or CrossAppAccessProvider without expectedIssuer is deprecated: the constructor logs one console.warn and that call signature is marked @deprecated. Behaviour is otherwise unchanged. Pass the issuer of the authorization server the credentials were registered with.

  fetchToken() throws AuthorizationServerMismatchError, before sending anything, when the provider's client information is bound to a different authorization server than the one it is called with. The AuthorizationServerMismatchError message no longer assumes the authorization-code callback; its fields are unchanged.

  OAuthTokensSchema and OAuthClientInformationSchema accept the optional issuer stamp, so a provider that reads storage back through them keeps it. auth() overwrites it on every save.

Patch Changes …

What's Changed

• [v1.x] fix(server): read HTTP request bodies with a size limit and bound JSON-RPC batch length by @maxisbey in https://github.com/modelcontextprotocol/typescript-sdk/pull/2717
• fix(auth): preserve resource URI without trailing slash (#1968) by @MukundaKatta in https://github.com/modelcontextprotocol/typescript-sdk/pull/1972
• chore: bump version to 1.30.1 by @claude[bot] in https://github.com/modelcontextprotocol/typescript-sdk/pull/2848

New Contributors

• @MukundaKatta made their first contribution in https://github.com/modelcontextprotocol/typescript-sdk/pull/1972

Full Changelog: https://github.com/modelcontextprotocol/typescript-sdk/compare/1.30.0...1.30.1

Minor Changes

• #1624 6032170 Thanks @SamMorrowDrums! - Add request-time OAuth scope challenges for tools, resources, resource templates, and prompts. Each primitive's scopeChallenge callback receives the parsed request and verified authentication info, then either continues or returns the exact scope set for an insufficient_scope response. requireScopes provides a small helper for static all-of checks.

  createMcpHandler and Streamable HTTP transports return HTTP 403 with an insufficient_scope challenge before handler execution or SSE setup. The preflight is active whenever a registered primitive carries a scopeChallenge callback — there is no handler- or transport-level configuration. The challenge's WWW-Authenticate header is built by the same formatter as the bearer-auth 401/403 answers, and its resource_metadata parameter is derived from the verified AuthInfo: requireBearerAuth / verifyBearerToken now stamp their configured resourceMetadataUrl onto the AuthInfo they return (new optional AuthInfo.resourceMetadataUrl field), with a fallback to the well-known location for an HTTP(S) RFC 8707 resource identifier; the parameter is omitted when neither is available. …

Minor Changes

• #1624 6032170 Thanks @SamMorrowDrums! - Add request-time OAuth scope challenges for tools, resources, resource templates, and prompts. Each primitive's scopeChallenge callback receives the parsed request and verified authentication info, then either continues or returns the exact scope set for an insufficient_scope response. requireScopes provides a small helper for static all-of checks.

  createMcpHandler and Streamable HTTP transports return HTTP 403 with an insufficient_scope challenge before handler execution or SSE setup. The preflight is active whenever a registered primitive carries a scopeChallenge callback — there is no handler- or transport-level configuration. The challenge's WWW-Authenticate header is built by the same formatter as the bearer-auth 401/403 answers, and its resource_metadata parameter is derived from the verified AuthInfo: requireBearerAuth / verifyBearerToken now stamp their configured resourceMetadataUrl onto the AuthInfo they return (new optional AuthInfo.resourceMetadataUrl field), with a fallback to the well-known location for an HTTP(S) RFC 8707 resource identifier; the parameter is omitted when neither is available. …

Patch Changes

• #2698 7b781ed Thanks @maxisbey! - Read Streamable HTTP request bodies with a size limit. Every SDK-owned body read — WebStandardStreamableHTTPServerTransport (and the Node transport built on it), createMcpHandler, toNodeHandler, and createMcpHonoApp's JSON pre-parse — now stops at 4 MiB by default (the limit the legacy SSE transport already uses; the Express adapter and stdio bound their reads too) and answers 413 Payload Too Large before anything is parsed. toWebRequest (when it reads the Node stream itself) now rejects once the body exceeds the limit with an error whose name is 'RequestBodyTooLargeError' and status is 413, and toNodeHandler answers that with 413; hand-wired callers of toWebRequest should handle the rejection or pass a pre-parsed body, and isLegacyRequest reports such a request as non-legacy so the modern handler answers it. JSON-RPC batch arrays are limited to 100 messages; a longer batch is answered 400 / -32600 and none of it is dispatched.

  The limit is configurable with a new maxRequestBodySize option (bytes, default DEFAULT_MAX_REQUEST_BODY_SIZE = 4 MiB, exported from @modelcontextprotocol/server) on …