SEP-1730: SDKs Tiering System

[ihrpr]

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:

• clarify tier1 should implement full support before the new version release. This gives two weeks between the release candidate announcement and the new version release.
• soften the triage timing requirement a bit -- from 48 hours to 2 business days.

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:

• Feature Support Uncertainty: No standardized way to know which SDKs support specific MCP features (OAuth, client/server/system features, like sampling, transports)
• Maintenance Expectations: Unclear commitment levels for bug fixes, security patches, and feature updates
• Implementation Timelines: No visibility into when SDKs will support new protocol versions and features

Specification

Tier Definitions

Tier 1: fully supported

SDKs in this tier provides full protocol implementation and is well supported

Requirements:

• Feature complete and full support of the protocol
  • All conformance tests pass
  • New protocol features before the new spec version release. (There is two week window between Release Candidate and the new protocol version release)
• SDK maintenance
  • Acknowledge and triage issues within two business days
  • Resolve security and critical bugs within seven days
  • Stable release and SDK versioning clearly documented
• Documentation
  • Comprehensive documentation with examples for all features
  • Published dependency update policy

Tier 2: commitment to be fully supported

SDKs with established implementations actively working toward full protocol support.

Requirements:

• Feature complete and full support of the protocol
  • 80% of conformance tests pass
  • New protocol features implemented within six months
• SDK maintenance
  • Active issue tracking and management
  • At least one stable release
• Documentation
  • Basic documentation covering core features
  • Published dependency update policy
• Commitment to move to Tier1
  • Published roadmap showing intent to achieve Tier 1 or, if SDK will remain in Tier 2 indefinitely, a transparent roadmap about the direction of the SDK and reasons for not being feature complete

Tier 3: Experimental

Early-stage or specialized SDKs exploring the protocol space.

Characteristics:

• No feature completeness guarantees
• No stable release requirement
• May focus on specific use cases or experimental features
• No timeline commitments for updates
• Suitable for niche implementations that may remain at this tier

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 result

Loading

Compliance Scoring:

• SDKs receive a percentage score based on test results
• Scores can be displayed as badges (e.g., "90% MCP Compliant")
• Tier 1: 100% compliance required
• Tier 2: 80% compliance required
• Tier 3: No minimum requirement

Tier Advancement Process

1. Self-Assessment: Maintainers evaluate their SDK against tier criteria
2. Application: Submit tier advancement request with evidence
3. Review: Community review period (2 weeks)
4. Validation: Automated conformance testing, github stats on issues
5. Decision: Tier assignment by MCP maintainers

Tier Relegation Process

1. Auto validation:
   1. compliance tests continuously not passing for four week for Tier 1
   2. 20% of compliance tests continuously not passing for four week for Tier 2
2. Issues:
   1. Issues are not addressed within two months

Requirements matrix

Feature	SDK A	SDK B	SDK C
Protocol Features support (Conformance tests)	85%	60%%	100%
GitHub support stats	10 days	100 days	5 days
Documentation (self reported)	Good	Minimal	Good
Tier (computed from above)	Tier 2	Tier 3	Tier 1

Rationale

Why Three Tiers?

• Tier 1 ensures users have well supported, fully-featured SDK
• Tier 2 provides a clear pathway for improving SDKs
• Tier 3 allows experimentation without creating barriers to entry

Why Time-Based Commitments?

While the community raised concerns about rigid timelines, they provide:

• Clear expectations for users
• Measurable goals for maintainers
• Flexibility through tier progression

Why Not Just Feature Matrices?

Feature matrices alone don't communicate:

• Maintenance commitment
• Quality standards
• Support expectations

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:

• Version support may be incomplete (e.g., supports <date> except OAuth)
• No indication of maintenance commitment or issue response times
• Lacks information about security patch timelines
• Doesn't communicate dependency update policies
• Version numbers alone don't indicate production readiness

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:

• Existing SDKs continue to function
• Classification is opt-in initially
• Grace period for existing SDKs to achieve tier status

Security Implications

• Tier 1 SDKs must address security issues within 7 days
• All tiers encouraged to follow security best practices
• Conformance tests include security validation

Implementation Plan

• Finalize simplified conformance test suite - Nov 4, 2025
• SDK maintainers self-assess and apply for tiers - Nov 14, 2025
• Initial tier assignments - before the November spec release
• Implement full compliance tests
• Implement automatic issue tracking analysis for SDKs

Community Impact

SDK Maintainers

• Clear goals for improvement
• Recognition for quality implementations
• Structured pathway for advancement

SDK Users

• Informed selection of SDKs
• Clear expectations for support
• Confidence in tier 1 implementations

Ecosystem

• Improved overall SDK quality
• Standardized feature support
• Healthy competition between implementations

References

• SDK Maintainer Meeting Notes (#1648)
• SDK Harmonization Goals (#1444)
• Conformance Testing SEP (DRAFT)

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:

• execute “hello world” tool
• Get prompt
• Get completion
• Get resource template
• Receive notifications

What is needed form SDKs maintainers: implement everything server based on a spec. Spec will look like:

• Tool “say_hello” to return simple text
• Tool “show_image” to return and image
• Tool “tool_with_logging” to return structured output in a format <> and log three events: start, process, end
• Tool "tool_with_notifications" to return structured output in a format <> and have two notifications <>

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.

[scottslewis]

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.

[halter73]

New 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.

[mikekistler]

I'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.

[ihrpr]

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?

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.

[ihrpr]

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, adding

[scottslewis]

What 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.