Implement SEP-2133: Extensions framework for MCP #2188

Activity

1. felixweinberger

   added this to 2026-07-28 Spec Implementationon May 29, 2026
2. github-project-automation

   moved this to Todo in 2026-07-28 Spec Implementationon May 29, 2026
3. mattzcarey commented on May 29, 2026

   

   mattzcarey

   on May 29, 2026

   Member

   More actions

   Status — SEP-2133 (Extensions Framework)

   Track: B — independent, starts now, lives in the same transport/core files as 2549/2243.
   Spec: seps/2133-extensions.md · merged into spec

   What's done — partial

   • ✅ Allow servers / clients to advertise extensions in the capability object #1630 (merged 2025) — capabilities.extensions field on ClientCapabilities/ServerCapabilities (by @chughtapan). Live in main:
     • packages/core/src/types/spec.types.ts — extensions?: { [key: string]: JSONObject } on both capability types
     • packages/core/src/types/schemas.ts — Zod z.record(z.string(), JSONObjectSchema).optional()
   • ✅ [v1.x backport] Allow servers / clients to advertise extensions in the capability object #1811 (merged) — v1.x backport of Allow servers / clients to advertise extensions in the capability object #1630

   What's still needed

   • R-2133-2: id grammar {prefix}/{name} per _meta key rules; prefix mandatory (reverse-DNS SHOULD). No validator in main today.
   • R-2133-3: SDK registrar so a server registers a handler for ext-x/foo and the dispatcher routes the method.
   • R-2133-8: disabled-by-default; explicit opt-in (constructed without ext opt-in → discover carries no capabilities.extensions).
   • R-2133-10: servers SHOULD gate ext-specific output on the client declaring the matching capability.
   • R-2133-13: unsupported extension → revert to core or reject with error.
   • R-2133-11 / 12 / 7 / 9 (guidance): validate ext-supplied data as untrusted; doc the supported list; breaking change → new identifier; back-compat within identifier.

   Closed exploration

   • feat(core): add extension() registrar for SEP-2133 capability-aware custom methods #1868 (closed) — extension(id, settings, {peerSchema?}) registrar returning ExtensionHandle, wraps custom-method API with peer-capability gating. Lots of design discussion (11 comments).
   • feat(core): BaseContext.ext / RequestEnv.ext plugin slot (SEP-2133 mechanism) #2061 (closed) — BaseContext.ext / RequestEnv.ext plugin slot (the generic mechanism plugins like tasksPlugin populate).

   Open PR stack

   • The extension slot mechanism (BaseContext.ext) is part of the v2-stateless stack ([SEP-2663] refactor!: remove 2025-11 experimental tasks #2128–[SEP-2575][SEP-2567] 2026-06 stateless support: stdio + InMemory transports #2132). The Tasks Extension Implement SEP-2663: Tasks Extension #2189 will be the first real consumer.

   Outstanding work shape

   1. Land the registrar API (revive feat(core): add extension() registrar for SEP-2133 capability-aware custom methods #1868 against the v2 dispatcher, or build it on top of BaseContext.ext).
   2. Add the id-grammar validator.
   3. Add a couple of reference extensions (Tasks at Implement SEP-2663: Tasks Extension #2189; Apps spec lives elsewhere but exercises the same mechanism).
   4. Docs: README enumerates supported extensions (R-2133-12).

   Coordination

   • This is the dependency for Implement SEP-2663: Tasks Extension #2189 (Tasks). Start now per the track plan.
   • The ext.* slot also gets used by SessionCompat and tasksPlugin, so the shape needs to land before Implement SEP-2663: Tasks Extension #2189 can.
4. felixweinberger

   assigned

   KKonstantinov

   on May 29, 2026
5. felixweinberger

   moved this from Todo to Done in 2026-07-28 Spec Implementationon Jun 24, 2026
6. felixweinberger

   closed this as completedby moving to Done in 2026-07-28 Spec Implementationon Jun 24, 2026