SDK Tiers changedcommunity/sdk-tiers
Nearest release: v2.1.321, published 5 hours after upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Upstream edited this page at 9 Nov 2026 13:29 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 9 Nov 2026 13:37 UTC.
Upstream edited
Recorded here
Lines+34added
Lines−71removed
From line
1
where the diff opens
First seen
14 Aug 2026
this site's first read of the page
Recorded edits4to this page, all time
# SDK Tiers ## Tier requirements ## Conformance testing ## Tier advancement ## Tier relegation ## Issue triage labels # SDK Tiering System ## Overview ## Tier Requirements ## Conformance Testing ## Tier Advancement ## Tier Relegation ## Issue Triage Labels
The whole hunk
from line 1, old and new numbered
/
from line 1
1# SDK Tiering System
1# SDK Tiers
22
3> Feature completeness, protocol support, and maintenance commitment levels for Model Context Protocol SDKs
3> What each SDK tier requires, how conformance is measured, how an SDK moves between tiers, and the issue labels SDK repositories must use.
44
5The MCP SDK Tiering System establishes clear expectations for feature completeness, protocol support, and maintenance commitments across official and community-driven SDKs. This helps developers choose the right SDK for their needs and provides SDK maintainers with a clear path to improving adoption expectations.
5This page defines the three SDK tiers, what each requires, how an SDK moves between them, and the issue labels SDK repositories must use. The tiers were adopted by [SEP-1730](https://modelcontextprotocol.io/seps/1730.md), a Specification Enhancement Proposal (SEP), and are changed by a Process SEP. The [SDK Working Group](https://modelcontextprotocol.io/community/working-groups/sdk.md) operates them, and each SDK's current tier is shown on the [SDKs page](https://modelcontextprotocol.io/docs/sdk.md).
66
7> [!NOTE]
8>
9> **Key dates:**
10>
11> * **January 23, 2026**: Conformance tests available
12> * **February 23, 2026**: Official SDK tiering published
13>
14> Between January 23 and February 23, SDK maintainers can work with the
15> Conformance Testing working group to adopt the tests and set up GitHub issue
16> tracking with the standardized labels defined below.
7## Tier requirements
178
18## Overview
9Tier 1 SDKs are fully supported and implement every non-experimental feature, including optional capabilities such as sampling and elicitation. SDKs in Tier 2 are actively maintained and working toward full specification support, and those in Tier 3 are experimental, partially implemented, or specialized. Experimental features and protocol extensions (such as Tasks and MCP Apps) are not required for any tier.
1910
20SDKs are classified into three tiers based on feature completeness, maintenance commitments, and documentation quality:
21
22* **Tier 1**: Fully supported SDKs with complete protocol implementation, including all
23 non-experimental features and optional capabilities like sampling and elicitation
24* **Tier 2**: Actively-maintained SDKs working toward full protocol specification support
25* **Tier 3**: Experimental, partially implemented, or specialized SDKs
26
27Experimental features and protocol extensions (such as Tasks and MCP Apps) are not required
28for any tier.
29
30## Tier Requirements
31
3211| Requirement | Tier 1: Fully Supported | Tier 2: Commitment to Full Support | Tier 3: Experimental |
3312| - | - | - | - |
3413| **Conformance Tests** | 100% pass rate | 80% pass rate | No minimum |
from line 19
4019| **Dependency Policy** | Published update policy | Published update policy | Not required |
4120| **Roadmap** | Published roadmap | Published plan toward Tier 1 or explanation for remaining Tier 2 | Not required |
4221
43**Issue Triage** means labeling and determining whether an issue is valid, not resolving the issue.
22**Issue Triage** means labeling an issue and determining whether it is valid, not resolving it.
4423
45**Critical Bug** refers to P0 issues (see [Priority labels](#priority-only-if-actionable) for
46detailed criteria).
24**Critical Bug** means a `P0` issue as defined under [Priority labels](#priority-only-if-actionable).
4725
48**Stable Release** is a published version explicitly marked as production-ready (e.g., version `1.0.0`
49or higher without pre-release identifiers like `-alpha`, `-beta`, or `-rc`).
26**Stable Release** means a published version explicitly marked as production-ready, for example version `1.0.0` or higher without a pre-release identifier such as `-alpha`, `-beta`, or `-rc`.
5027
51**Clear Versioning** means following idiomatic versioning patterns with documented
52breaking change policies, so users can understand compatibility expectations when upgrading.
28**Clear Versioning** means following idiomatic versioning patterns with a documented breaking-change policy.
5329
54**Roadmap** outlines concrete steps and work items that track implementation of required MCP
55specification components (non-experimental features and optional capabilities as described in
56[Conformance Testing](#conformance-testing)), giving users visibility into upcoming feature support.
30**Roadmap** means a published set of concrete steps and work items tracking implementation of the required specification components (non-experimental features and optional capabilities, as scoped under [Conformance testing](#conformance-testing)).
5731
58## Conformance Testing
32## Conformance testing
5933
60All SDKs are evaluated using [automated conformance tests](https://github.com/modelcontextprotocol/conformance)
61that validate protocol support against the published specifications. SDKs receive a conformance score
62based on test results:
34Conformance is measured with the [conformance test suite](https://github.com/modelcontextprotocol/conformance). Each official SDK runs the suite against its default branch and publishes the results.
6335
64* **Tier 1**: 100% conformance required
65* **Tier 2**: 80% conformance required
66* **Tier 3**: No minimum requirement
36The pass rates in the matrix are calculated against applicable required tests only:
6737
68Conformance scores are calculated against **applicable required tests** only:
69
7038* Tests for the specification version the SDK targets
7139* Excluding tests marked as pending or skipped
7240* Excluding tests for experimental features
from line 41
7341* Excluding legacy backward-compatibility tests (unless the SDK claims legacy support)
7442* Excluding tests labeled `disputed` in the conformance repository, until the dispute is resolved
7543
76Conformance testing validates that SDKs correctly implement the protocol by running standardized test
77scenarios and checking protocol message exchanges. See [Tier Relegation](#tier-relegation) for how
78temporary test failures are handled.
44Sustained test failures are handled under [Tier relegation](#tier-relegation).
7945
80## Tier Advancement
46## Tier advancement
8147
82SDK maintainers can request tier advancement by:
48To request a higher tier, an SDK's maintainers:
8349
841. Self-assessing against tier requirements
852. Opening an issue in the [modelcontextprotocol/modelcontextprotocol](https://github.com/modelcontextprotocol/modelcontextprotocol) repository with supporting evidence
863. Passing automated conformance testing
874. Receiving approval from SDK Working Group maintainers
501. Self-assess the SDK against the [tier requirements](#tier-requirements).
512. Open an issue in the [modelcontextprotocol/modelcontextprotocol](https://github.com/modelcontextprotocol/modelcontextprotocol) repository with the supporting evidence.
523. Pass the conformance threshold for the requested tier on the latest stable release.
534. Obtain approval from the SDK Working Group.
8854
89The SDK Working Group reviews advancement requests and makes final tier assignments.
55The SDK Working Group makes the final tier assignment and records the decision and rationale as set out in its [charter](https://modelcontextprotocol.io/community/working-groups/sdk.md).
9056
91## Tier Relegation
57## Tier relegation
9258
93An SDK may be moved to a lower tier if existing conformance tests on the latest stable release fail
94continuously for 4 weeks:
59An SDK may be moved to a lower tier if existing conformance tests on its latest stable release fail continuously for 4 weeks:
9560
96* **Tier 1 → Tier 2**: Any conformance test fails
97* **Tier 2 → Tier 3**: More than 20% of conformance tests fail
61* **Tier 1 to Tier 2**: any conformance test fails.
62* **Tier 2 to Tier 3**: more than 20% of conformance tests fail.
9863
9964An SDK may also be relegated if issues remain unaddressed for two months.
10065
101## Issue Triage Labels
66The SDK Working Group may likewise relegate a Tier 1 SDK that consistently fails to surface specification deprecations as required by [Tier 1 SDK Obligations](https://modelcontextprotocol.io/community/feature-lifecycle.md#tier-1-sdk-obligations). The group decides each relegation and records it with its rationale.
10267
103SDK repositories must use consistent labels to enable automated reporting on issue handling metrics.
104Tier calculations use these metrics to measure triage response times (time from issue creation to
105first label) and critical bug resolution times (time from P0 label to issue close).
68## Issue triage labels
10669
70SDK repositories must use the labels below. Two tier metrics are computed from them: triage response time (issue creation to first label) and critical bug resolution time (`P0` label to close).
71
10772### Type (pick one)
10873
10974| Label | Description |
from line 77
11277| `enhancement` | Request for new feature |
11378| `question` | Further information requested |
11479
115Repositories using [GitHub's native issue types](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/managing-issue-types-in-an-organization)
116satisfy this requirement without needing type labels.
80Repositories using [GitHub's native issue types](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/managing-issue-types-in-an-organization) satisfy this requirement without type labels.
11781
11882### Status (pick one)
11983
120Use these exact label names across all repositories to enable consistent reporting and analysis.
84Use these exact label names in every repository.
12185
12286| Label | Description |
12387| - | - |
from line 100
136100| `P2` | Moderate issues, valuable feature requests |
137101| `P3` | Nice to haves, rare edge cases |
138102
139**P0 (Critical)** issues are:
103A `P0` issue is either:
140104
141* **Security vulnerabilities** with CVSS score ≥ 7.0 (High or Critical severity)
142* **Core functionality failures** that prevent basic MCP operations: connection establishment,
143 message exchange, or use of core primitives (tools, resources, prompts)
105* A security vulnerability with a CVSS score of 7.0 or higher (High or Critical severity)
106* A core functionality failure that prevents basic MCP operations: connection establishment, message exchange, or use of the core primitives (tools, resources, prompts)
144107
No line in this hunk matches that.