[RFC] Standardizing Server Implementation Versioning & Discovery

[arielszmerla]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

[RFC] Standardizing Server Implementation Versioning & Discovery

The Challenge: The "Version Blindness" Problem

As the MCP ecosystem expands, we are hitting a technical wall where managing server updates is becoming functionally impossible. While the protocol currently handles protocol versioning (handshaking), there is no standard for implementation versioning. This creates several critical failure points:

• Silent Failures: A server update changes a tool’s schema (e.g., adding a required argument), but the client and LLM have no programmatic way to "know" until the runtime call fails.
• Opaque Upgrades: When pulling new versions via npx or Docker, it is difficult to verify which version of the business logic is actually live.
• Schema Drift: Without a "Version Getter" pattern, the LLM's context window can easily become de-synced from the server’s actual capabilities.

Proposed Direction

We need a lightweight, standard way for a server to broadcast its own version and capability manifest. I suggest we explore:

1. Standardized Metadata: Including a serverVersion (SemVer) field within the initialize result or as a reserved property in getServerInfo.
2. Explicit Breaking Changes: Establishing a community convention on how to signal tool deprecation (e.g., versioned tool names vs. metadata flags).
3. Discovery Utility: A standardized "Version Getter" pattern where clients can query a reserved version method before passing definitions to the LLM.

What can be done before implementation

Since the protocol is currently designed to be minimal, I want to hear from those building production-grade integrations:

• Current Workarounds: How are you signaling breaking changes today? Are you versioning tool names (e.g., search_v2) or relying on the LLM to adapt to schema changes on the fly?
• Handshake vs. Method: Would adding a meta field to the initialization process be sufficient, or do we need a dedicated discovery method?
• Contract Testing: Should we develop a standard for "Capability Negotiation" to prevent clients from even attempting to call incompatible server versions?

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other