[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

[armorer-labs]

The capability-hash idea is really appealing because a lot of safety assumptions ride on clients having an accurate picture of what a server can do right now. Silent drift is not just an ergonomics bug; it can become a policy bug if an agent is reasoning from stale tool schemas or cached expectations.\n\nOne thing I would love to see preserved in any version/discovery scheme is the ability to distinguish:\n- implementation/version drift\n- capability-surface drift\n- annotation/policy-signaling drift\n\nThose matter differently for operations. A server can keep the same name and even the same semantic version while still becoming meaningfully riskier if a destructive tool appears, an approval hint disappears, or a schema changes in a way that broadens what an argument can do.\n\nSo a discovery model that lets clients notice not only "the server changed" but also "the trust profile changed" would be especially valuable.