Allow servers / clients to advertise extensions in the capability object by chughtapan · Pull Request #1630 · modelcontextprotocol/typescript-sdk · GitHub

According to SEP-2133, the protocol supports extensions which be be advertised in the capabilities object. This PR adds this field to the SDK

Motivation and Context

This enables extensions to build upon the typescript-sdk

How Has This Been Tested?

Existing and new tests pass.

Breaking Changes

No

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

Additional context

Extensions currently must use the experimental field as a workaround. This adds a dedicated extensions field (record of URI → object) to ServerCapabilitiesSchema, enabling capabilities like extensions["io.modelcontextprotocol/grouping"]: { listChanged: true }. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Use "extension identifiers" (vendor-prefix/extension-name) instead of "URIs" per the SEP-2133 Extensions specification. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

⚠️ No Changeset found

Latest commit: 72ac715

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1630

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1630

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1630

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1630

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1630

commit: 72ac715

Needs to be both on client and server #1475

Addresses PR feedback: extensions need to be on both client and server capability objects per SEP-2133. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…tObjectSchema The merge with main brought in modelcontextprotocol#1612 which replaced AssertObjectSchema with JSONObjectSchema, but the extensions fields were not updated. Also fixes spec.types.ts to use JSONObject (matching experimental) for bidirectional type compatibility. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

This fix is needed — we've been hitting this in production building MCP Apps servers with x428 precondition support. The extensions field (now formally in the spec via SEP-2133) is silently stripped during initialize parsing, making getClientCapabilities().extensions always undefined.

The ext-apps SDK's getUiCapability() function explicitly acknowledges this gap in its JSDoc ("pending SEP-1724"), but the compile-time type widening it uses doesn't help at runtime — the data is already gone by the time getClientCapabilities() returns.

Our current workaround is intercepting _onrequest on the raw Server to capture extensions before Zod parsing:

const rawServer = mcpServer.server as any;
const origOnRequest = rawServer._onrequest?.bind(rawServer);
if (origOnRequest) {
  rawServer._onrequest = (request: any, extra: any) => {
    if (request?.method === "initialize" && request?.params?.capabilities?.extensions) {
      rawExtensions = request.params.capabilities.extensions;
    }
    return origOnRequest(request, extra);
  };
}

This is fragile (depends on SDK internals) and we'd love to drop it. The Go SDK already shipped extensions support (go-sdk#794). Would be great to get this merged.

Thanks @chughtapan

@ochafik does this need something else? It still shows "unable to merge" on my side.

+1 to this fix being needed, otherwise there is no way to detect MCP apps capability, and distinguish between Claude code vs. Claude chat (modelcontextprotocol/ext-apps#521). How might we get this merged soon @ochafik?

Heyyy... any updates here / is anything blocking us from merging this improvement + bug-fix?

This one didn't make it to 1.28.0?

…#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

chughtapan and others added 3 commits March 4, 2026 22:33

Fix extensions field comment to use correct SEP-2133 terminology

cef2b2f

Use "extension identifiers" (vendor-prefix/extension-name) instead of "URIs" per the SEP-2133 Extensions specification. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Use generic test-extension identifier in extensions capability test

bc8c2a0

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

chughtapan requested a review from a team as a code owner March 5, 2026 06:51

chughtapan changed the title Groups/extensions capability Allow servers / clients to advertize extensions in the capability object Mar 5, 2026

Merge branch 'main' into groups/extensions-capability

a6af4bd

chughtapan mentioned this pull request Mar 5, 2026

Add grouping extension implementation with tests and examples modelcontextprotocol/experimental-ext-grouping#11

Draft

3 tasks

chughtapan and others added 2 commits March 5, 2026 09:03

Add extensions field to ClientCapabilities

3dab53b

Addresses PR feedback: extensions need to be on both client and server capability objects per SEP-2133. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Merge branch 'main' into groups/extensions-capability

1b73042

dmytrobaltak mentioned this pull request Mar 6, 2026

[TS SDK Bug] server.getClientCapabilities() does not seem to include extensions modelcontextprotocol/ext-apps#521

Closed

ochafik approved these changes Mar 9, 2026

View reviewed changes

Merge branch 'main' into groups/extensions-capability

2ace039

chughtapan changed the title Allow servers / clients to advertize extensions in the capability object Allow servers / clients to advertise extensions in the capability object Mar 22, 2026

olaservo mentioned this pull request Mar 22, 2026

Add TypeScript SDK for the Skills Extension SEP modelcontextprotocol/experimental-ext-skills#71

Closed

3 tasks

ochafik enabled auto-merge (squash) March 23, 2026 23:56

Merge branch 'main' into groups/extensions-capability

72ac715

ochafik merged commit 677511b into modelcontextprotocol:main Mar 24, 2026
13 checks passed

This was referenced Mar 27, 2026

ci: format fetch-spec-types output with prettier #1782

Merged

Add extensions #1475

Closed

localden mentioned this pull request Mar 29, 2026

[v1.x backport] Allow servers / clients to advertise extensions in the capability object #1811

Merged

9 tasks

mattzcarey mentioned this pull request May 29, 2026

Implement SEP-2133: Extensions framework for MCP #2188

Closed

Allow servers / clients to advertise extensions in the capability object by chughtapan · Pull Request #1630 · modelcontextprotocol/typescript-sdk · GitHub

Uh oh!

Allow servers / clients to advertise extensions in the capability object - #1630

Allow servers / clients to advertise extensions in the capability object#1630
ochafik merged 9 commits into
modelcontextprotocol:mainfrom
chughtapan:groups/extensions-capability

chughtapan commented Mar 5, 2026

Uh oh!

changeset-bot Bot commented Mar 5, 2026 •
edited
Loading

Uh oh!

Uh oh!

pkg-pr-new Bot commented Mar 5, 2026 •
edited
Loading

Uh oh!

Uh oh!

dmytrobaltak commented Mar 5, 2026

Uh oh!

lokkju commented Mar 8, 2026

Uh oh!

ochafik left a comment

Uh oh!

chughtapan commented Mar 11, 2026

Uh oh!

asana-jau commented Mar 12, 2026

Uh oh!

asana-jau commented Mar 20, 2026

Uh oh!

Uh oh!

shays10 commented Mar 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Allow servers / clients to advertise extensions in the capability object by chughtapan · Pull Request #1630 · modelcontextprotocol/typescript-sdk · GitHub

Uh oh!

Allow servers / clients to advertise extensions in the capability object - #1630

Conversation

chughtapan commented Mar 5, 2026

Motivation and Context

How Has This Been Tested?

Breaking Changes

Types of changes

Checklist

Additional context

Uh oh!

changeset-bot Bot commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ No Changeset found

Uh oh!

pkg-pr-new Bot commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dmytrobaltak commented Mar 5, 2026

Uh oh!

lokkju commented Mar 8, 2026

Uh oh!

ochafik left a comment

Choose a reason for hiding this comment

Uh oh!

chughtapan commented Mar 11, 2026

Uh oh!

asana-jau commented Mar 12, 2026

Uh oh!

asana-jau commented Mar 20, 2026

Uh oh!

Uh oh!

shays10 commented Mar 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

changeset-bot Bot commented Mar 5, 2026 •
edited
Loading

pkg-pr-new Bot commented Mar 5, 2026 •
edited
Loading