Repository navigation
SEP-1730: SDKs Tiering System #1730
Description
Activity
- changed the title [-]SEP - :SDKs Tiering System[/-] [+]SEP-1730: SDKs Tiering System[/+] on Oct 29, 2025
From the point of view of a consumer of these sdks, I like that this proposal is beginning to introduce time expectations (e.g. New protocol features implemented within two weeks) for at least Tier 1 projects.
I believe, however, to generate long-term dev community trust it will eventually be necessary to go further and require project-level release timing/cadence expectations (at least). e.g. consistent yearly/bi-yearly/quarterly/monthly, etc milestone and/or full releases...at the Tier 1 level anyway if not lower tiers. FWIW: I'm just starting a book by Jimmy Wales entitled: The Seven Rules of Trust.
One reason for this: even if new spec features are actually implemented in two weeks, that doesn't mean that they will actually be usable by sdk consumers unless expectations about release schedules can be communicated (from project team) and actually achieved consistently. Just the testing/verification/releng coordination and cross-language/interoperability issues involved in doing this for all (Tier 1) sdks could be a significant resources, coordination, versioning, and releng challenge.
I know it's early for mcp, and so perhaps too early for applying the same release expectations for all (even Tier 1) sdks (and their dependencies of course). However, it might be a good start to set the specification release cadence expectations...along with 1 or 2 by agreement, and stay with that for a year+, to see all the sdks can conform...and what it takes resource-wise for them to do so....and then adjust the timing...if it's not working well enough. My $0.03.
Reacted by Inna HarperNew protocol features implemented within two weeks
Within two weeks of what? Final ratification? If so, can we be stricter and require Tier 1 SDKs implement all new protocol features two weeks before fully ratifying a new protocol version? I think it makes sense to have support for features prior to ratification at least in some sort of opt-in draft spec mode. Otherwise, we unnecessarily increase the risk of finding out about protocol issues too late after ratification.
I think it's common for standards bodies to require multiple reference implementations for new features before ratification. Otherwise, we risk end up getting ourselves into a C++ modules situation. I don't want to hold up ratification because some SDKs fall behind on implementation though, I think as long as there are multiple Tier 1 SDKs that implement all the new features prior to ratification, it's okay to drop the rest to Tier 2.
Reacted by Inna HarperI'm generally in support of this proposal with a few minor tweaks to the details.
I'll echo @halter73 's request for clarity on the timeline for new feature implementation. And I'd like to add that the core maintainers need to be sensitive to this requirement and not approve a raft of new SEPs in a short period of time (as I fear might be about to happen).
Also, I'd like to soften the triage timing requirement a bit -- from 48 hours to 2 business days.
Reacted by Inna Harper and Robert FindleyWithin two weeks of what? Final ratification? If so, can we be stricter and require Tier 1 SDKs implement all new protocol features two weeks before fully ratifying a new protocol version?
Originally I was thinking two weeks after the release, but this makes sense. I'll update to "fully implemented" before a new protocol release, as we already had this practice for c# and typescript SDKs. Given that we have two weeks between release candidate and the protocol version, I think this is fair.
And I'd like to add that the core maintainers need to be sensitive to this requirement and not approve a raft of new SEPs in a short period of time (as I fear might be about to happen).
yes, totally agree, there is a two week freeze after the release candidate before the new version announcement
Also, I'd like to soften the triage timing requirement a bit -- from 48 hours to 2 business days.
makes sense, thank you, addingReacted by Stephen HalterWhat about the dependencies of the various sdk projects? Both wrt (especially) security issues and/or just plain ol bugs it's easy to see how one of the sdk's dependencies might not be able to provide (e.g.) Tier 1 level guarantees (e.g. because no maintenance resources) and thereby make it difficult or impossible for a Tier 1 MCP SDK project from being able to satisfy it's commitments wrt the Tiered compliance.
I have personally seen this as the project lead of a project that the Eclipse IDE has depended upon for > 15 years. i.e. there are few/little resources provided for the dependencies of the IDE by the Eclipse Foundation or the member community. and so maintenance and security issues can't be addressed in a timely way.
At some point, I think there is also the issue of having at least consistent licensing/copyright for sdk consumers...and how that's going to work for the sdk dependencies as well.
9 remaining items
- linked a pull request that will close this issueSEP-1730: SDK tiers definition #1777on Nov 11, 2025
Adding some retroactive commentary. First of all, I think this is a great step forward toward making the MCP ecosystem more transparent, secure, and homogeneous.
Some questions:
Published dependency update policy
Can you say more about what this means? Based on the phrasing, I assume this means a checked-in document outlining how and when dependencies are updated. Extrapolating, it should also say something about how dependencies are added, and the standards that must be met by new and existing dependencies. Should this SEP (or the associated CL) clarify what constitutes an acceptable policy of this nature? For example, what actions must taken when security vulnerabilities are discovered in dependencies.
For the initial version of tiering, we will go with the simplified version where we would have an Example server for each SDK and run simplified conformance tests against those.
What about client-side conformance? Is that out of scope for the initial tiering?
Finalize simplified conformance test suite - Nov 4, 2025
Is this done? Or rather, where can I track work on this?
SDK maintainers self-assess and apply for tiers - Nov 14, 2025
Is this deadline still accurate? If so, where should we apply for tiers?
Answering my own questions, from the SDK working group meeting :)
What about client-side conformance?
Client
Is this done? Or rather, where can I track work on this?
Yes, it's done: see https://github.com/modelcontextprotocol/conformance/blob/main/SERVER_REQUIREMENTS.md
Is this deadline still accurate?
No. SDKs are focused on support for the 2025-11-25 spec.
- marked SEP-1309: Specification Version Management #1309 as a duplicate of this issue on Nov 19, 2025
Reference Implementation Reminder
Hi @ihrpr!
This SEP was accepted 65 days ago.
A reminder that accepted SEPs should have a reference implementation to move to final status.
- Is there a reference implementation in progress?
- Do you need help or guidance with the implementation?
Let us know the current status!
This is an automated message from the SEP lifecycle bot.
Could this tiering system also be applied to SDKs that are not among the official SDKs? I maintain a Swift SDK that is more full-featured and spec-compliant than the official Swift SDK, and I'd like users to be able to discover it and compare tier ratings. To that end, it would be helpful to include highly rated non-official SDKs alongside the official ones in any list that is ultimately published.
Reacted by Luigi Pederzani- added a commit that references this issue on Aug 3, 2026
- added a commit that references this issue on Aug 3, 2026
- added a commit that references this issue on Aug 10, 2026
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
SEP-1730: SDKs Tiering System
Title: SDK Tiering System
Author: Inna Harper, Felix Weinberger
Status: Draft
Type: Standards Track
Created: 2025-10-29
Change log:
Abstract
This SEP proposes a tiering system for Model Context Protocol (MCP) SDKs to establish clear expectations for feature support, maintenance commitments, and quality standards. The system defines three tiers of SDK support with objective, measurable criteria for classification.
Motivation
The MCP ecosystem needs SDK harmonization to help users make informed decisions. Users currently face challenges:
Specification
Tier Definitions
Tier 1: fully supported
SDKs in this tier provides full protocol implementation and is well supported
Requirements:
Tier 2: commitment to be fully supported
SDKs with established implementations actively working toward full protocol support.
Requirements:
Tier 3: Experimental
Early-stage or specialized SDKs exploring the protocol space.
Characteristics:
Conformance Testing
All SDKs must undergo conformance testing using protocol trace validation: for details see Conformance Testing RFC (forthcoming). This SEP is not focusing on Conformance testing. For the initial version of tiering, we will go with the simplified version where we would have an Example server for each SDK and run simplified conformance tests against those.
sequenceDiagram participant SDK participant Test Suite participant Validator Test Suite->>SDK: Execute test scenario SDK->>Test Suite: Protocol messages Test Suite->>Validator: Submit trace Validator->>Test Suite: Compliance report Test Suite->>SDK: Pass/Fail resultCompliance Scoring:
Tier Advancement Process
Tier Relegation Process
Requirements matrix
Rationale
Why Three Tiers?
Why Time-Based Commitments?
While the community raised concerns about rigid timelines, they provide:
Why Not Just Feature Matrices?
Feature matrices alone don't communicate:
The tiering system combines feature support with quality guarantees.
Alternatives Considered
1. Feature Matrix Only
Rejected because: Doesn't communicate maintenance commitments or quality standards
2. Percentage-Based Scoring
Rejected because: Too granular and doesn't capture qualitative aspects like support
3. Properties-Based System
Rejected because: Multiple overlapping properties could confuse users
4. Latest Version Listing Only
Rejected because: Simply listing "supports MCP date" fails to capture critical information:
5. No Formal System
Rejected because: Current ad-hoc approach creates uncertainty for users
Backward Compatibility
This proposal introduces a new classification system with no breaking changes:
Security Implications
Implementation Plan
Community Impact
SDK Maintainers
SDK Users
Ecosystem
References
Appendix
Simplified conformance tests
While we are working on a comprehensive proposal for conformance testing which will take some time to implement, we want to move forward with at least some automated way to check if SDK has a full set of features. We will start from Servers features set, as we have many more servers than clients and the vast majority of developers using SDKs are Server implementers.
The most straightforward approach is to have an Example Server for each SDK, similar to to Everything Server. Then we will have Conformance Test Client with all the test cases we want to be able to test, for example:
What is needed form SDKs maintainers: implement everything server based on a spec. Spec will look like:
Given well defined spec for the server and SDK documentation, it should be easy to implement it with the help of any coding agent. We want to check it into each SDKs repo as it will serve as an example for server implementers.
Once each SDK has an Everything server, we will run the Conformance Test Client against it.