MCP Protocol News - September 25, 2026

Week of: September 25, 2026

---

Overview

The Model Context Protocol ecosystem saw a coordinated TypeScript SDK 2.1.0 release wave this week, headlined by DPoP sender-constrained token support (RFC 9449 / SEP-1932) and request-time OAuth scope challenges for tools, resources, and resource templates. Alongside the auth work, the SDK shipped body-size limits on Streamable HTTP handling, a codemod fix for v1→v2 migration, and the spec repository added an Infrastructure Working Group charter plus contributing and security documentation.

Stories

1. TypeScript SDK core and client 2.1.0 add DPoP sender-constrained access token support

Source: MCP TypeScript SDK Link: https://github.com/modelcontextprotocol/typescript-sdk/releases/tag/%40modelcontextprotocol%2Fcore%402.1.0

The @modelcontextprotocol/core@2.1.0 and @modelcontextprotocol/client@2.1.0 releases add DPoP (RFC 9449 / SEP-1932) sender-constrained access token support to the client. Developers opt in by implementing OAuthClientProvider.dpop() to return a DpopSession, alongside new helpers generateDpopKeyPair, accessTokenHash, and isDpopNonceChallenge. The auth flow paths — auth(), exchangeAuthorization, refreshAuthorization, and fetchToken — now sign a DPoP proof into token requests, retrying once on an authorization-server use_dpop_nonce challenge with client authentication re-applied per attempt, and the Streamable HTTP, SSE, and withOAuth transports present the token accordingly (see source for the full description).

Why it matters: DPoP binds access tokens to a client-held key, reducing the value of a stolen bearer token — a meaningful hardening step for MCP servers exposed over HTTP. For teams building remote MCP servers or gateways, SEP-1932 alignment means the SDK now supports an authorization-server capability that security-conscious deployments increasingly request. Adoption is opt-in, so existing OAuth integrations are unaffected unless they implement the new provider hook.

Impact Analysis: Teams running remote MCP servers should evaluate DPoP opt-in as part of their OAuth hardening roadmap now that the client SDK supports it.

2. Server and Node packages add request-time OAuth scope challenges

Source: MCP TypeScript SDK Link: https://github.com/modelcontextprotocol/typescript-sdk/releases/tag/%40modelcontextprotocol%2Fserver%402.1.0

@modelcontextprotocol/server@2.1.0 and @modelcontextprotocol/node@2.1.0 add request-time OAuth scope challenges for tools, resources, and resource templates. A scopeChallenge callback receives the parsed insufficient_scope response, and requireScopes combined with createMcpHandler and Streamable HTTP transports returns HTTP 403 with an insufficient_scope challenge before handler execution or SSE setup. The WWW-Authenticate header is built by the same formatter used for the resource_metadata parameter, and requireBearerAuth / verifyBearerToken now place resourceMetadataUrl onto the AuthInfo they return.

Why it matters: Scope enforcement that happens before handler execution gives MCP server authors a standards-shaped way to reject under-scoped calls without leaking tool behavior or partially opening SSE streams. It also closes a practical gap for hosts that need to discover why a call failed and which scope to request. Combined with the standard WWW-Authenticate framing, clients can drive re-authorization flows more reliably.

Impact Analysis: Server builders can now reject insufficiently scoped requests at the transport boundary rather than inside tool logic.

3. TypeScript SDK 1.30.1 bounds Streamable HTTP request bodies and JSON-RPC batch length

Source: MCP TypeScript SDK Link: https://github.com/modelcontextprotocol/typescript-sdk/releases/tag/1.30.1

Version 1.30.1 of the TypeScript SDK fixes server-side HTTP request body reading to enforce a size limit and bounds JSON-RPC batch length (#2717). The patch also preserves the resource URI without a trailing slash in auth handling (#1968), and bumps the package version (#2848). The release notes credit @MukundaKatta as a first-time contributor.

Why it matters: Unbounded request bodies and unbounded JSON-RPC batches are straightforward denial-of-service vectors for any network-exposed MCP server. This is a maintenance-line fix for teams still on the 1.x branch, and it signals the SDK maintainers are treating transport-level resource exhaustion as a first-class concern. Anyone running 1.30.0 or earlier in production over HTTP should upgrade.

Impact Analysis: Treat 1.30.1 as a security-relevant patch for any 1.x MCP server reachable over the network.

4. Express and Hono transport packages return 413 for oversized request bodies

Source: MCP TypeScript SDK Link: https://github.com/modelcontextprotocol/typescript-sdk/releases/tag/%40modelcontextprotocol%2Fexpress%402.0.1

@modelcontextprotocol/express@2.0.1 reads Streamable HTTP request bodies with a size limit (#2698). Every SDK-owned body read now stops at 413 Payload Too Large before anything is parsed, including WebStandardStreamableHTTPServerTransport (and the Node transport built on it), createMcpHandler, toNodeHandler, and createMcpHonoApp's JSON pre-parse. The error is named RequestBodyTooLargeError with status 413, and hand-wired callers of toWebRequest are advised to handle it (see source).

Why it matters: The same fix shipped in the Hono package (@modelcontextprotocol/hono@2.0.1), so framework-integrated MCP deployments across both Express and Hono now fail fast on oversized payloads rather than buffering them. This matters most for servers fronted directly by these frameworks without an upstream proxy limit. Hand-wired transport users need to check their error handling to avoid surfacing raw errors as 500s.

Impact Analysis: Framework-based MCP servers should upgrade to 2.0.1 and verify that oversized-body errors are surfaced as 413s rather than generic failures.

5. Codemod 2.1.0 fixes v1→v2 project-type inference for SDK path strings

Source: MCP TypeScript SDK Link: https://github.com/modelcontextprotocol/typescript-sdk/releases/tag/%40modelcontextprotocol%2Fcodemod%402.1.0

@modelcontextprotocol/codemod@2.1.0 fixes project-type inference so it no longer counts bare SDK paths that appear only in ordinary string data (#2765). Previously the v1→v2 codemod's source scanner matched any quoted @modelcontextprotocol/sdk/client|server subpath anywhere in a file, so a server path stored as data — example text, a log message, a config value — could misclassify a client-only project as both, rewriting shared type imports to @modelcontextprotocol/server and adding an unused dependency. The scanner now requires a module-specifier position such as static imports and re-exports.

Why it matters: Migration tooling that silently rewrites imports and adds spurious dependencies is a trust problem for anyone moving a codebase to the v2 package layout. This fix reduces false-positive rewrites, making the codemod safer to run across mixed client/server repositories. Teams that already ran an earlier codemod version should review their diff for stray @modelcontextprotocol/server dependencies.

Impact Analysis: Re-run or audit codemod output on client-only projects before committing v2 migrations.

6. Spec repository adds an Infrastructure Working Group charter

Source: MCP Specification Link: https://github.com/modelcontextprotocol/modelcontextprotocol/commit/c7400a0796045cbf102cb80b9b41422c7ce8e7af

A pull request adding an Infrastructure Working Group charter was merged into the MCP specification repository (#3385, authored by sambhav). The charter lands as documentation in the spec repo.

Why it matters: Working group charters are how protocol projects formalize ownership over areas that sit outside the core spec text — here, the operational and infrastructure concerns that matter to anyone hosting MCP servers at scale. For implementers, a chartered group is a vector for shaping proposals and reviewing changes that affect deployment, transport, and hosting assumptions. The underlying charter content is not described in the commit snippet; see source.

Impact Analysis: Infrastructure-focused contributors now have a named venue in the spec repo for hosting and transport concerns.

7. Spec repo adds contributing, community onboarding, and security links

Source: MCP Specification Link: https://github.com/modelcontextprotocol/modelcontextprotocol/commit/a99bdd15ea9ff96bf4d758aac907bbb27e9329dc

The specification site's home page now links to Contributing and Security resources (#3386, co-authored by Radoslav Dimitrov). A related merged pull request (#3379) covered contributing and community onboarding content in the spec repository.

Why it matters: Discoverability of contribution and vulnerability-reporting paths matters more as MCP implementations multiply across vendors. Surfacing the security link on the home page gives integrators a direct route to report protocol or implementation issues rather than routing them through ad hoc channels. It is process work rather than protocol work, but it lowers the barrier to participating in the spec's evolution.

Impact Analysis: Point contributors and security reporters to these spec-repo entry points rather than informal channels.

8. Documentation corrections land across spec pages and SEP examples

Source: MCP Specification Link: https://github.com/modelcontextprotocol/modelcontextprotocol/commit/dc48f37d9ee9f78081256e694ed11b73267787df

Two JSON examples in the published docs did not parse and were fixed: the Image Content example in the 2025-06-18/server/tools.mdx spec page was missing a comma after "mimeType", and the SEP-1330 "Legacy Single Select With Titles" example used curly quotes around enumNames with a default of "Green" instead of an enum value. Additional documentation fixes this week corrected a "Serves" typo in the resources capability text across the draft and 2026-07-28 pages, removed a duplicate footer border, and repaired an expired Discord invite on the Financial Services IG charter.

Why it matters: Invalid JSON in normative spec examples propagates into SDK tests, generated clients, and third-party tutorials, so these are more than cosmetic fixes. SEP-1330's default correction also removes a subtle inconsistency between the legacy and new-style select examples. Together the batch is routine maintenance that keeps copy-pasteable spec content trustworthy.

Impact Analysis: Anyone who copied these examples into tests or docs should re-pull the corrected versions.

Source Links

• MCP TypeScript SDK - @modelcontextprotocol/core@2.1.0
• MCP TypeScript SDK - @modelcontextprotocol/server@2.1.0
• MCP TypeScript SDK - 1.30.1
• MCP TypeScript SDK - @modelcontextprotocol/express@2.0.1
• MCP TypeScript SDK - @modelcontextprotocol/codemod@2.1.0
• MCP Specification - Merge pull request #3385 from sambhav/docs/infrastructure-wg-charter
• MCP Specification - Add Contributing and Security links to the home page (#3386)
• MCP Specification - docs: fix invalid JSON in two example code blocks (#3381)