Uh oh!
There was an error while loading. Please reload this page.
[v1.x backport] Allow servers / clients to advertise extensions in the capability object - #1811
Conversation
…#1630) Backport of #1630 to v1.x branch. Adds the `extensions` field to `ClientCapabilities` and `ServerCapabilities` to allow servers and clients to advertise extension support in the capability object, per SEP-2133. Adapted from the main branch implementation to use v1.x types: - Uses `object` type in spec.types.ts (matching existing `experimental` field) - Uses `AssertObjectSchema` in Zod schemas instead of `JSONObjectSchema` :house: Remote-Dev: homespace
🦋 Changeset detectedLatest commit: 2225fd1 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
🏠 Remote-Dev: homespace
There was a problem hiding this comment.
LGTM, straightforward backport mirroring the existing experimental field pattern.
Extended reasoning...
Overview
This PR adds an optional extensions field to ClientCapabilities and ServerCapabilities in three files: src/spec.types.ts (TypeScript interfaces), src/types.ts (Zod schemas), and test/server/mcp.test.ts (two new test cases). It is a backport of #1630 to the v1.x branch.
Security risks
None. The change adds an optional field to capability negotiation objects. No auth, crypto, or permissions code is affected.
Level of scrutiny
Low scrutiny warranted. The new extensions field uses the exact same pattern as the existing experimental field ({ [key: string]: object } in the interface, z.record(z.string(), AssertObjectSchema).optional() in the Zod schema). This is a mechanical, pattern-following addition with no design ambiguity.
Other factors
- Two tests cover both server-side and client-side extension capability advertisement.
- No outstanding reviewer comments or prior reviews to address.
- The changeset bot flagged a missing changeset, but that is a maintainer decision, not a code correctness issue.
There was a problem hiding this comment.
LGTM — straightforward backport adding optional extensions field to capabilities, following the existing experimental field pattern exactly.
Extended reasoning...
Overview
This PR backports #1630 to the v1.x branch, adding an optional extensions field to both ClientCapabilities and ServerCapabilities. Four files are touched: the changeset, the TypeScript interface types (spec.types.ts), the Zod runtime schemas (types.ts), and a test file with two new integration tests.
Security risks
None. The change adds an optional field to capability advertisement interfaces. No auth, crypto, permissions, or user input handling is affected. The field type ({ [key: string]: object } / z.record(z.string(), AssertObjectSchema).optional()) is identical to the existing experimental field, so no new attack surface is introduced.
Level of scrutiny
Low scrutiny is appropriate. This is a mechanical, pattern-following addition of a single optional field to two interfaces/schemas. The implementation exactly mirrors the existing experimental field in both the TypeScript types and Zod schemas. The two new tests adequately verify the feature works for both server-side and client-side capability advertisement.
Other factors
- No outstanding reviewer comments or unaddressed feedback.
- The changeset is included and correctly marked as a minor version bump.
- The PR follows the repository's existing conventions for capability fields.
- Tests cover both directions (server advertising to client, client advertising to server).
Uh oh!
There was an error while loading. Please reload this page.
Ported functional changes from upstream v1.x (17 commits behind, v1.28.0 through v1.29.0+). Only retained-fork-surface changes applied; auth, HTTP, and CI-only commits skipped. Changes ported: - stdio: ReadBuffer maxBufferSize limit (modelcontextprotocol#2239) - stdio: windowsHide always on Win32, removed isElectron() (modelcontextprotocol#1640) - stdio: try/catch error handling on read buffer overflow - types: extensions capability on ClientCapabilities/ServerCapabilities (modelcontextprotocol#1811) - types: size field on ResourceSchema (modelcontextprotocol#1575) - zod-compat: prioritize zod issues with path formatting (modelcontextprotocol#1503) - protocol: conditional abort controller cleanup (modelcontextprotocol#1462) Intentionally kept: - AuthInfo import from ./shared/auth-info.js (not reverted to auth/types.js) - All removed transports, auth, and HTTP modules stay out
Backport of #1630 to the
v1.xbranch.According to SEP-2133, the protocol supports extensions which can be advertised in the capabilities object. This PR adds this field to the v1.x SDK.
Motivation and Context
This enables extensions to build upon the typescript-sdk v1.x release line.
Adaptations from main
The v1.x branch has a flatter directory structure and different type primitives, so the following adaptations were made:
src/spec.types.ts(instead ofpackages/core/src/types/spec.types.ts): uses{ [key: string]: object }to match the existingexperimentalfield pattern, sinceJSONObjectdoesn't exist on v1.xsrc/types.ts(instead ofpackages/core/src/types/types.ts): usesAssertObjectSchemato match the existingexperimentalfield pattern, sinceJSONObjectSchemadoesn't exist on v1.xtest/server/mcp.test.ts(instead oftest/integration/test/server/mcp.test.ts): same tests, adapted to the v1.x test structureHow Has This Been Tested?
New tests pass (
should register and advertise server extensions capabilityandshould advertise client extensions capability to server).Breaking Changes
No
Types of changes
Checklist