Experimental and vendor-specific MCP extensions

If you’ve seen a key like anthropic/alwaysLoad in a tool definition and wondered whether your Model Context Protocol (MCP) server needs it too, this part is for you. Beyond the official extensions sit two more layers: vendor conventions that a single host honours, and experimental extensions still incubating. Both are worth knowing about, and both need care. This is part 29 of my series on what an MCP server does under the 2026-07-28 specification, after part 28 on enterprise-managed authorization and client credentials. Part 23 explained how extensions work in general. The facts are as I read them in October 2026.

In brief #

1. Vendor conventions are _meta keys and capabilities that one host honours and others silently ignore, so they’re safe as enhancements but never for behaviour you require.
2. As of October 2026, the Claude Code conventions I know of are three tool keys and one server capability:anthropic/maxResultSizeChars ,anthropic/alwaysLoad ,anthropic/requiresUserInteraction andclaude/channel , thoughclaude/channel isn’t available on 2026-07-28 connections.
3. Experimental extensions incubate in experimental-ext-* repositories under a Working Group or Interest Group, and become official only through an Extensions Track Specification Enhancement Proposal (SEP).
4. Two are worth watching: Interceptors, a proposed primitive of validators and mutators (SEP-2624), and Variants, several parallel variants of one server’s surface, chosen per request (SEP-2053).
5. My advice: most teams don’t need an extension of their own. Reach for one only for new protocol behaviour that more than one client will implement.

Vendor conventions: keys one host honours #

Hosts define their own _meta keys and capabilities. Each works only in the host that defines it and is silently ignored elsewhere, so it’s safe to add as an enhancement and nothing more. These are the ones I know of as of October 2026; Claude Code lists its own in its MCP documentation:

The first key is easy to confuse with the token limits in part 9. Claude Code has both: a token limit on a tool’s output, and a separate 50,000-character threshold above which it saves a successful text result to a file. For text content, a tool that sets anthropic/maxResultSizeChars uses that value in place of the token limit as well, so users don’t need to raise that limit for the tool; a result with an image stays under it. Part 9’s advice still holds: return a summary and resource links rather than whole documents.

I think of three layers. Core behaviour works in every host; official extensions are negotiated and degrade gracefully; vendor conventions are ignored where unsupported, so never put required behaviour in that last layer:

Experimental extensions: what’s incubating #

Experimental extensions, which an amendment to SEP-2133 brought into MCP’s governance, live in experimental-ext-* repositories in the MCP GitHub organization. As part 23 explains, each must belong to a Working Group or Interest Group and be clearly labelled experimental, Core Maintainers can archive or remove it, and it becomes official only through an Extensions Track SEP.

Interceptors

The Interceptors Working Group wants to standardize how context operations are intercepted, validated and transformed at key points in the agent lifecycle. It proposes interceptors as a new MCP primitive of two types:

• Validators inspect a payload and return pass or fail.
• Mutators transform a payload, for example by redacting personally identifiable information (PII).

Interceptors would be discoverable and invocable through MCP’s existing JSON-RPC 2.0 patterns, and deployable in-process, as a sidecar or as a remote service. Its planned deliverables include:

• software development kit (SDK) libraries in several languages;

• sample interceptors for PII redaction, schema validation and audit logging;

• a common sidecar or proxy runtime, so platform teams can add interceptors without modifying servers;

• a command-line tool for testing. The proposal is SEP-2624, an open pull request that superseded SEP-1763 in April 2026 and names the methods interceptors/list and interceptor/invoke. The working group’s charter still lists SEP-1763 as its draft work item. Here is the idea as a policy chain, drawn from the group’s stated goals rather than a finished specification, so details will change:

Variants

The experimental-ext-variants repository is the reference implementation of SEP-2053, the Server Variants extension, which proposes a way for one MCP server to expose several parallel variants of its surface at once. Each variant has an id, a description and key-value hints that clients use to choose one, and the choice is made per request through _meta. The uses it describes include model-specific tool descriptions, different tool sets per agent type, a compact variant for tight context budgets, and application programming interface (API) versions.

It’s early. The repository has Go examples, and its SDK packages are planned. The SEP’s pull request was closed in September 2026, to be reopened after discussion with the primitive-grouping working group.

My advice for Interceptors and Variants alike: watch them, and if you build on either, keep it behind a feature flag, as part 23 suggests for anything experimental.

Building your own extension #

If none of the above fits your domain, these are the steps:

1. Pick an identifier under a reversed domain you own, such ascom.example/approvals .
2. Define a settings object for capability negotiation, where{} means “supported, no settings”.
3. Reserve your names. Use your prefix for new methods,_meta keys and notification types.
4. Specify fallback behaviour for peers that don’t support the extension.
5. Version through settings flags, and mint a new identifier only for breaking changes.
6. If it’s broadly useful, bring it to a working group and follow the path from experimental repository to SEP thatpart 23 describes.

Part 23 shows steps 1, 2 and 4 in Python, with a made-up approvals extension.

What follows is my advice, not a rule from the specification. Most teams don’t need a custom extension. A well-designed tool with a clear outputSchema (part 8) gets you surprisingly far, and so do resources with sensible Uniform Resource Identifier (URI) schemes and a few prompts. Reach for an extension when you need new protocol behaviour that tools can’t express, such as a new negotiation, a new lifecycle or a new rendering surface, and when more than one client will implement it.

Method and caveats #

• Built from my guide’s chapter on experimental and vendor-specific extensions, written against the 2026-07-28 specification. The vendor keys and capabilities are as of October 2026; check the host’s documentation before relying on one.
• Where the proposals’ own records are newer than my notes (which SEP specifies Interceptors, and what Variants covers), this article follows the SEP-2624 pull request and the Variants repository, as checked on 8 October 2026.