[poita]

Summary

Adds an optional extensions map to Remote, giving MCP extensions a place to publish server-level information in the Server Card — data a client needs before any session exists.

Keys are extension identifiers following the _meta key naming rules (e.g. io.modelcontextprotocol/events); values are objects whose contents are defined by each extension. The map shape matches ServerCapabilities.extensions, and JSONValue / JSONObject / JSONArray are inlined verbatim from the core schema alongside the existing inlined MetaObject and Icon.

This is not a declaration of extension support. The presence or absence of an entry says nothing about whether the server supports that extension, and an entry need not match capabilities.extensions. Support is negotiated via server/discover, which may vary per user. docs/discovery.md states this normatively (clients MUST NOT infer support from the card).

Motivation

From the tasks-events-wg discussion of SEP-3415 (Events): webhook receivers need the server's ed25519 signing keys (a JWK set) and, optionally, egress IP ranges from an origin they already trust. The agreed home is:

ServerCard.remotes[x].extensions["io.modelcontextprotocol/events"].webhooks

This PR only adds the generic container; the contents of each entry are defined by the extension itself (SEP-3415 for events).

Changes

• schema.ts: Remote.extensions?: { [key: string]: JSONObject }, plus inlined JSON types; schema.json regenerated.
• docs/discovery.md: clarify that extensions carries extension-defined information, not support, and that clients MUST NOT infer support from it.
• README.md: mention server-level extension information in the remote-endpoint bullet.
• Examples: valid/remote-extensions.json (illustrative events/webhooks entry) and invalid/non-object-extension-info.json (entries must be objects).

Compatibility

Additive and optional; existing cards remain valid.

Note: the generated JSONValue (string | integer | boolean, no null) is identical to the core schema/draft/schema.json output from typescript-json-schema with --defaultNumberType integer; kept identical to core rather than diverging here.

Verification

• npm run check — schema.json in sync, tsc passes
• npm run validate — all 9 examples pass; the new invalid example was confirmed to be (wrongly) accepted before the schema change
• npm run format:check

🤖 Generated with Claude Code

https://claude.ai/code/session_01BzSw9zenmbDjJXgmtp94Pv

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	ext-server-card	76c9875	Oct 26 2026, 10:46 AM