The MCP configuration schema in 1.0.0 offers three transport variants, one of which the MCP specification has since moved to Deprecated. A plugin can be fully conformant to Agent Plugins 1.0.0 and still ship a transport that MCP tells implementers not to adopt.
Specifics, so this is checkable:
schemas/1.0.0/mcp.schema.json defines sseServer with "type": { "const": "sse" }, and §7.2.1 describes it as "the deprecated HTTP+SSE transport defined by the MCP 2024-11-05 specification".
The MCP 2026-07-28 changelog, Deprecated item 2, goes further than the prose here suggests:
Reclassify the HTTP+SSE transport (deprecated since protocol version 2025-03-26) as Deprecated under the feature lifecycle policy (SEP-2596). Migrate to Streamable HTTP.
That is a formal lifecycle state with a removal window attached, not the older soft deprecation. Major changes item 9 in the same revision also removes SSE stream resumability and message redelivery (Last-Event-ID and SSE event IDs) from Streamable HTTP.
Why it seems worth addressing rather than leaving implicit:
The schema treats all three variants as equally valid, so a validator built on it reports nothing. §11.1 requires clients to support "at least one of the stdio or streamable-http variants", which means a plugin declaring sse may be silently skipped by a conformant client that never implemented it. The failure surfaces as a server that quietly does not load, and the plugin author has no signal at authoring time.
Some options, in rough order of how invasive they are:
- Note in §7.2.1 that MCP 2026-07-28 classifies HTTP+SSE as Deprecated under SEP-2596, and point at Streamable HTTP. Documentation only, no schema change.
- Add
"deprecated": true to sseServer in the schema. JSON Schema 2020-12 supports the annotation, tooling can surface it, and nothing breaks.
- Decide the versioning question explicitly: whether the Agent Plugins MCP schema tracks MCP revisions, and what happens to
sse when HTTP+SSE reaches Removed. Since the schema version is pinned to the spec version (§10.1), a plugin pinned to 1.0.0 keeps a valid sse declaration indefinitely, and it is not obvious from the text what should happen then.
Option 1 or 2 would have been enough to catch it at authoring time in my case.
Context on how I hit this: I maintain a linter for the MCP 2026-07-28 migration and added an Agent Plugins input surface to it, so I was reading both specs side by side. Happy to open a PR for option 1 or 2 if either is the direction you want.
The MCP configuration schema in 1.0.0 offers three transport variants, one of which the MCP specification has since moved to Deprecated. A plugin can be fully conformant to Agent Plugins 1.0.0 and still ship a transport that MCP tells implementers not to adopt.
Specifics, so this is checkable:
schemas/1.0.0/mcp.schema.jsondefinessseServerwith"type": { "const": "sse" }, and §7.2.1 describes it as "the deprecated HTTP+SSE transport defined by the MCP 2024-11-05 specification".The MCP 2026-07-28 changelog, Deprecated item 2, goes further than the prose here suggests:
That is a formal lifecycle state with a removal window attached, not the older soft deprecation. Major changes item 9 in the same revision also removes SSE stream resumability and message redelivery (
Last-Event-IDand SSE event IDs) from Streamable HTTP.Why it seems worth addressing rather than leaving implicit:
The schema treats all three variants as equally valid, so a validator built on it reports nothing. §11.1 requires clients to support "at least one of the stdio or streamable-http variants", which means a plugin declaring
ssemay be silently skipped by a conformant client that never implemented it. The failure surfaces as a server that quietly does not load, and the plugin author has no signal at authoring time.Some options, in rough order of how invasive they are:
"deprecated": truetosseServerin the schema. JSON Schema 2020-12 supports the annotation, tooling can surface it, and nothing breaks.ssewhen HTTP+SSE reaches Removed. Since the schema version is pinned to the spec version (§10.1), a plugin pinned to 1.0.0 keeps a validssedeclaration indefinitely, and it is not obvious from the text what should happen then.Option 1 or 2 would have been enough to catch it at authoring time in my case.
Context on how I hit this: I maintain a linter for the MCP 2026-07-28 migration and added an Agent Plugins input surface to it, so I was reading both specs side by side. Happy to open a PR for option 1 or 2 if either is the direction you want.