SEP-2053: Server Variants extension#2053
SEP-2053: Server Variants extension#2053sambhav wants to merge 3 commits intomodelcontextprotocol:mainfrom
Conversation
sambhav
force-pushed
the
variant-extension
branch
from
b555e3f to
197095a
Compare
sambhav
force-pushed
the
variant-extension
branch
from
197095a to
4aaf28a
Compare
sambhav
force-pushed
the
variant-extension
branch
from
4aaf28a to
1b0db67
Compare
|
Hi, @sambhav 👋 This looks interesting and potentially useful. One thought:
While the SEP guidelines do say that the reference can come after acceptance, this proposal is sufficiently complex that I think it would be worthwhile to create an implementation first. It would allow you to prove that it will work as intended, as well as discover any unforeseen issues. This would help convince a sponsor of its validity and that it is in its optimal form prior to core maintainer review. When a complex SEP is accepted without a reference implementation, we don't have an easy / clean way to reverse it or correct it before the community gets their hands on it and discovers the problems themselves. That's just an issue with the current process, and why I'm making this suggestion to you. You can take it or leave it. |
|
Happy to provide a reference implementation as well. A close real world example that largely implements something similar is the Github MCP server. Let me see if I can trivially expose the same using this extension. Additionally, this is proposed as an extension instead of a core part of the spec so that we can experiment with it easily. A big part of the reason I modeled it as an extension was to provide a sandbox to iterate on it without the baggage of b/w incompatible migrations in the core spec.
|
|
I really like that |
|
Hi @sambhav! I wanted to let you know about a related proposal that references SEP-2053 extensively. SEP-2290: Content Negotiation Extension — PR #2317 It addresses the same root problem (MCP servers cannot adapt to heterogeneous clients) but from a different angle: clients declare structured feature tags once at The two proposals are complementary rather than competing:
Both proposals independently arrived at the same vocabulary axes ( A detailed side-by-side comparison is available at: https://github.com/schlpbch/ext-content-negotiation/blob/master/SEP2053_COMPARISON.md Would love your feedback, especially on the complementarity angle and whether you see value in both being implemented together. |
5 participants
Summary
This PR introduces SEP-2053: Server Variants, which proposes a server-level variant mechanism enabling MCP servers to expose multiple variants simultaneously. Each variant includes a unique identifier, human-readable description, and key-value hints that intelligent clients can use to select an appropriate variant for their context.
The primary motivation is cross-agent tool reusability - enabling the same MCP tools to serve fundamentally different agent architectures (coding assistants, research agents, task automation agents, conversational agents, etc.) or models (claude, gpt, gemini etc) with optimized surface areas tailored to each use case.
Motivation and Context
Problem: Server capabilities in MCP are currently monolithic - a single capability definition must serve all clients equally, regardless of which LLM is interpreting them, the client's use case, capabilities, or context constraints.
Solution: Server variants allow servers to expose parallel configurations (e.g.,
claude-optimized,gpt-optimized,compact,coding-assistant,automation-agent) that clients can intelligently select based on their context.Why is this needed?
How Has This Been Tested?
This is a specification proposal (SEP) with:
Real-world validation will come from prototype implementations once the SEP is accepted.
Breaking Changes
None - This is fully backward compatible:
_metaon a per-request basisTypes of changes
Checklist
Additional context
Design Principles:
_meta(stateless)Packaging: Currently specified as an MCP extension to minimize core schema churn.
Related Issues:
SEP Status: Draft, seeking sponsor