[Schema][Server][Client] SEP-2133: Extensions framework (capability negotiation + ExtensionRegistry + extensible dispatch)

[chr-hertel]

Implements SEP-2133 for the MCP Spec 2026-07-28 release.

Tracked by umbrella #335. Prerequisite for SEP-2663 (Tasks) and SEP-1865 (MCP Apps).

Spec summary

Establishes a formal extension process with reverse-DNS identification (e.g. io.modelcontextprotocol/oauth-client-credentials), independent versioning, and a Standards Track path. Extensions are advertised via an extensions field in ClientCapabilities / ServerCapabilities during initialization. Extensions can declare their own JSON-RPC methods and notifications.

PHP SDK changes

• Schema: Add an extensions map to ClientCapabilities and ServerCapabilities in src/Schema/ (each entry keyed by reverse-DNS extension ID).
• Capability negotiation: Update initialize request/response handlers in src/Server/Handler/ and src/Client/Handler/ to round-trip the extensions map and store negotiated set on the session/request.
• Builder API: Server::builder()->addExtension(ExtensionInterface $ext) and matching method on Client::builder(). Introduce ExtensionRegistry alongside Registry so handlers can query "is extension X negotiated for this request?".
• Method routing: Protocol::processInput() dispatches a fixed method set today. Make the request/notification handler map extensible so extensions can register their own method handlers.
• Per-request capabilities: RequestContext needs typed accessor for per-request extension data (SEP-2663 uses per-request capability flags).

Related

• Umbrella [2026-07-28] Extensions framework + Tasks + MCP Apps #335
• Blocks SEP-2663 (Tasks) and SEP-1865 (MCP Apps) sub-issues

[chr-hertel]

Implemented via #443, #454. ExtensionInterface now carries getMessages()/getRequestHandlers() directly, plus ExtensionIdentifier for reverse-DNS naming and modern-lifecycle dispatch.