SEP-XXXX: Extension Versioning

[LucaButBoring]

SEP-2133 establishes that extensions evolve independently of the core protocol and SHOULD be versioned, but it leaves the versioning approach unspecified and defers extension dependency declaration to future work. This proposal fills both gaps with a single mechanism. Each extension carries a semantic version in its settings object, and MAY declare the core protocol version its behavior depends on. A difference in the major version means the two peers are incompatible; they negotiate a shared major version through inline retry, as they negotiate a protocol version (see protocol version negotiation). A difference in the minor version is not a conflict: each peer uses the features common to both, and neither rejects the other. A difference in the patch version changes nothing about how the peers interoperate. A new error code, -32005 (Unsupported Extension Version), reports a major-version mismatch and tells the client which major versions the server supports, so it can retry against one of them.

Motivation and Context

SEP-2133 scoped itself narrowly: it defined how extensions are governed, identified, and negotiated, but excluded two compatibility concerns from its scope. Under Not Specified, it omits both extension dependencies on core protocol versions and a concrete versioning approach, recording only that "Extensions SHOULD be versioned, but exact versioning approach is not specified here." Three problems follow from those omissions, and each currently surfaces as a runtime failure rather than a negotiated outcome.

1. An extension's protocol-version dependency is undiscoverable.
2. An extension cannot roll out a breaking change of its own.
3. Optional, non-breaking features cannot be advertised.

This proposal address all three issues by introducing a versioning scheme and negotiation pattern that can generalize across extensions.

Based on #11 from and my previous versioning draft.

How Has This Been Tested?

Hasn't.

Breaking Changes

Technically if extensions are already using version as a settings field, but as far as I've seen they aren't.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

AI Use Disclosure: Claude wrote this and I made it revise its own work for several hours after I tore it apart.