Summary
AHP has a well-defined extension point for state — the _meta slot, present on ~22 shapes and explicitly documented as provider-specific metadata. It has no equivalent for the method space, and the method space is closed and conformance-asserted. A host that needs a host-specific command today has no sanctioned way to add one, and no guarantee that whatever namespace it picks won't collide with a future first-party method.
Whichever way this is resolved, it should be resolved before 1.0: reserving a namespace afterwards can't retroactively protect method names already in use, and generalizing a "reject unadvertised methods" rule afterwards would break hosts that relied on its absence.
The current state
The command surface is closed and asserted exhaustive. types/version/message-checks.ts pins the method set with an exact-match type assertion:
type _CheckCommandMapKeys = _Exact<keyof CommandMap, _ExpectedCommands>;
_ExpectedCommands enumerates all 27 request methods, with sibling assertions for client notifications, server notifications, and server commands. Adding anything outside that list is, by construction, off-spec.
There is no reserved extension namespace. Neither docs/specification/ nor types/ mentions a vendor, extension, experimental, or implementation-defined method prefix. LSP reserves $/; MCP has experimental capabilities. AHP has nothing.
The spec already mandates the strict posture in one place. mcp-channel.md:
A method outside every advertised capability set MUST be rejected by the host with JSON-RPC -32601 Method not found. Clients SHOULD NOT speculate beyond the advertisement — capability sets are the only source of truth for what's served.
That principle is a natural fit for the top-level method space too, and it's consistent with the "capabilities are the only source of truth" framing in versioning.md. But if it's generalized after 1.0, every host currently serving a non-standard method becomes non-conformant with no migration path short of a MAJOR bump.
Why hosts hit this
Real hosts accumulate surfaces the protocol doesn't model — host-level settings, managing the set of workspaces/repositories a host exposes, host-specific artifacts a session produces, host-scoped configuration writes. Some of these are genuinely host-specific and shouldn't be in the core protocol; others are candidates for eventual standardization but aren't there yet.
Today the options are all bad:
- Invent an unnamespaced method — risks colliding with a future first-party method, and violates the exhaustive
CommandMap assertion.
- Overload
_meta on state shapes to carry what is really an RPC — pushes imperative operations into a read model, and gives no request/response correlation or error channel.
- Fork the protocol.
None of these are what a host implementer should have to choose between, and the choice gets frozen at 1.0.
Options
- Reserve a namespace (e.g. a
x-/$/ext/ prefix, or reverse-DNS like com.example.doSomething) and exclude it from the CommandMap exactness assertion. Cheap, and it does the one thing that must happen pre-1.0: guarantee the reserved space will never collide with a first-party method.
- Capability-advertised extension commands — a host declares its extension methods in the handshake, and the mcp-channel rule generalizes: methods outside the union of standard methods and advertised extensions MUST be rejected with
-32601. More machinery, but it makes extension methods discoverable and keeps "capabilities are the only source of truth" true at every layer.
- Explicitly decline to support extension methods and state that the method space is closed. Also a legitimate answer — but it should be a stated decision, since it tells host implementers to stop and take the gap upstream rather than route around it.
Option 1 is the minimum that has to land pre-1.0; option 2 is the fuller answer if there's appetite.
Related
Adjacent to, but distinct from, the unknown-field/unknown-enum tolerance question in #366 — that one is about forward compatibility of shapes AHP defines, this one is about whether implementations may define anything at all.
Summary
AHP has a well-defined extension point for state — the
_metaslot, present on ~22 shapes and explicitly documented as provider-specific metadata. It has no equivalent for the method space, and the method space is closed and conformance-asserted. A host that needs a host-specific command today has no sanctioned way to add one, and no guarantee that whatever namespace it picks won't collide with a future first-party method.Whichever way this is resolved, it should be resolved before 1.0: reserving a namespace afterwards can't retroactively protect method names already in use, and generalizing a "reject unadvertised methods" rule afterwards would break hosts that relied on its absence.
The current state
The command surface is closed and asserted exhaustive.
types/version/message-checks.tspins the method set with an exact-match type assertion:_ExpectedCommandsenumerates all 27 request methods, with sibling assertions for client notifications, server notifications, and server commands. Adding anything outside that list is, by construction, off-spec.There is no reserved extension namespace. Neither
docs/specification/nortypes/mentions a vendor, extension, experimental, or implementation-defined method prefix. LSP reserves$/; MCP hasexperimentalcapabilities. AHP has nothing.The spec already mandates the strict posture in one place.
mcp-channel.md:That principle is a natural fit for the top-level method space too, and it's consistent with the "capabilities are the only source of truth" framing in
versioning.md. But if it's generalized after 1.0, every host currently serving a non-standard method becomes non-conformant with no migration path short of a MAJOR bump.Why hosts hit this
Real hosts accumulate surfaces the protocol doesn't model — host-level settings, managing the set of workspaces/repositories a host exposes, host-specific artifacts a session produces, host-scoped configuration writes. Some of these are genuinely host-specific and shouldn't be in the core protocol; others are candidates for eventual standardization but aren't there yet.
Today the options are all bad:
CommandMapassertion._metaon state shapes to carry what is really an RPC — pushes imperative operations into a read model, and gives no request/response correlation or error channel.None of these are what a host implementer should have to choose between, and the choice gets frozen at 1.0.
Options
x-/$/ext/prefix, or reverse-DNS likecom.example.doSomething) and exclude it from theCommandMapexactness assertion. Cheap, and it does the one thing that must happen pre-1.0: guarantee the reserved space will never collide with a first-party method.-32601. More machinery, but it makes extension methods discoverable and keeps "capabilities are the only source of truth" true at every layer.Option 1 is the minimum that has to land pre-1.0; option 2 is the fuller answer if there's appetite.
Related
Adjacent to, but distinct from, the unknown-field/unknown-enum tolerance question in #366 — that one is about forward compatibility of shapes AHP defines, this one is about whether implementations may define anything at all.