Merge pull request modelcontextprotocol#1777 from modelcontextprotocol/ihrpr/sdk-tiers

SEP-1730: SDK tiers definition

Author: localden

AGENTS.md

@@ -60,3 +60,7 @@ npm run check:seps       # Check SEP documents
 # Workflow
 npm run prep             # Full prep before committing (check, generate, format)
 ```
+
+## Commit Guidelines
+
+- Do not include model names or details (e.g., "Claude", "Opus") in commit messages

docs/community/sdk-tiers.mdx

@@ -0,0 +1,141 @@
+---
+title: SDK Tiering System
+description: Feature completeness, protocol support, and maintenance commitment levels for Model Context Protocol SDKs
+---
+
+The 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.
+
+<Note>
+  **Key dates:**
+  - **January 23, 2026**: Conformance tests available
+  - **February 23, 2026**: Official SDK tiering published
+
+Between January 23 and February 23, SDK maintainers can work with the
+Conformance Testing working group to adopt the tests and set up GitHub issue
+tracking with the standardized labels defined below.
+
+</Note>
+
+## Overview
+
+SDKs are classified into three tiers based on feature completeness, maintenance commitments, and documentation quality:
+
+- **Tier 1**: Fully supported SDKs with complete protocol implementation, including all
+  non-experimental features and optional capabilities like sampling and elicitation
+- **Tier 2**: Actively-maintained SDKs working toward full protocol specification support
+- **Tier 3**: Experimental, partially implemented, or specialized SDKs
+
+Experimental features (such as Tasks) and protocol extensions (such as MCP Apps) are not required
+for any tier.
+
+## Tier Requirements
+
+| Requirement                 | Tier 1: Fully Supported                                                                  | Tier 2: Commitment to Full Support                               | Tier 3: Experimental   |
+| --------------------------- | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ---------------------- |
+| **Conformance Tests**       | 100% pass rate                                                                           | 80% pass rate                                                    | No minimum             |
+| **New Protocol Features**   | Before new spec version release, timeline agreed per release based on feature complexity | Within 6 months                                                  | No timeline commitment |
+| **Issue Triage**            | Within 2 business days                                                                   | Within a month                                                   | No requirement         |
+| **Critical Bug Resolution** | Within 7 days                                                                            | Within two weeks                                                 | No requirement         |
+| **Stable Release**          | Required with clear versioning                                                           | At least one stable release                                      | Not required           |
+| **Documentation**           | Comprehensive with examples for all features                                             | Basic documentation covering core features                       | No minimum             |
+| **Dependency Policy**       | Published update policy                                                                  | Published update policy                                          | Not required           |
+| **Roadmap**                 | Published roadmap                                                                        | Published plan toward Tier 1 or explanation for remaining Tier 2 | Not required           |
+
+**Issue Triage** means labeling and determining whether an issue is valid, not resolving the issue.
+
+**Critical Bug** refers to P0 issues (see [Priority labels](#priority-only-if-actionable) for
+detailed criteria).
+
+**Stable Release** is a published version explicitly marked as production-ready (e.g., version `1.0.0`
+or higher without pre-release identifiers like `-alpha`, `-beta`, or `-rc`).
+
+**Clear Versioning** means following idiomatic versioning patterns with documented
+breaking change policies, so users can understand compatibility expectations when upgrading.
+
+**Roadmap** outlines concrete steps and work items that track implementation of required MCP
+specification components (non-experimental features and optional capabilities as described in
+[Conformance Testing](#conformance-testing)), giving users visibility into upcoming feature support.
+
+## Conformance Testing
+
+All SDKs are evaluated using [automated conformance tests](https://github.com/modelcontextprotocol/conformance)
+that validate protocol support against the published specifications. SDKs receive a conformance score
+based on test results:
+
+- **Tier 1**: 100% conformance required
+- **Tier 2**: 80% conformance required
+- **Tier 3**: No minimum requirement
+
+Conformance scores are calculated against **applicable required tests** only:
+
+- Tests for the specification version the SDK targets
+- Excluding tests marked as pending or skipped
+- Excluding tests for experimental features
+- Excluding legacy backward-compatibility tests (unless the SDK claims legacy support)
+
+Conformance testing validates that SDKs correctly implement the protocol by running standardized test
+scenarios and checking protocol message exchanges. See [Tier Relegation](#tier-relegation) for how
+temporary test failures are handled.
+
+## Tier Advancement
+
+SDK maintainers can request tier advancement by:
+
+1. Self-assessing against tier requirements
+2. Opening an issue in the [modelcontextprotocol/modelcontextprotocol](https://github.com/modelcontextprotocol/modelcontextprotocol) repository with supporting evidence
+3. Passing automated conformance testing
+4. Receiving approval from SDK Working Group maintainers
+
+The SDK Working Group reviews advancement requests and makes final tier assignments.
+
+## Tier Relegation
+
+An SDK may be moved to a lower tier if existing conformance tests on the latest stable release fail
+continuously for 4 weeks:
+
+- **Tier 1 → Tier 2**: Any conformance test fails
+- **Tier 2 → Tier 3**: More than 20% of conformance tests fail
+
+## Issue Triage Labels
+
+SDK repositories must use consistent labels to enable automated reporting on issue handling metrics.
+Tier calculations use these metrics to measure triage response times (time from issue creation to
+first label) and critical bug resolution times (time from P0 label to issue close).
+
+### Type (pick one)
+
+| Label         | Description                   |
+| ------------- | ----------------------------- |
+| `bug`         | Something isn't working       |
+| `enhancement` | Request for new feature       |
+| `question`    | Further information requested |
+
+Repositories 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 needing type labels.
+
+### Status (pick one)
+
+Use these exact label names across all repositories to enable consistent reporting and analysis.
+
+| Label                | Description                                             |
+| -------------------- | ------------------------------------------------------- |
+| `needs confirmation` | Unclear if still relevant                               |
+| `needs repro`        | Insufficient information to reproduce                   |
+| `ready for work`     | Has enough information to start                         |
+| `good first issue`   | Good for newcomers                                      |
+| `help wanted`        | Contributions welcome from those familiar with codebase |
+
+### Priority (only if actionable)
+
+| Label | Description                                                     |
+| ----- | --------------------------------------------------------------- |
+| `P0`  | Critical: core functionality failures or high-severity security |
+| `P1`  | Significant bug affecting many users                            |
+| `P2`  | Moderate issues, valuable feature requests                      |
+| `P3`  | Nice to haves, rare edge cases                                  |
+
+**P0 (Critical)** issues are:
+
+- **Security vulnerabilities** with CVSS score ≥ 7.0 (High or Critical severity)
+- **Core functionality failures** that prevent basic MCP operations: connection establishment,
+  message exchange, or use of core primitives (tools, resources, prompts)

docs/docs.json

@@ -366,6 +366,7 @@
             "pages": [
               "community/governance",
               "community/sep-guidelines",
+              "community/sdk-tiers",
               "community/working-interest-groups",
               "community/antitrust"
             ]

docs/docs/sdk.mdx

@@ -3,7 +3,7 @@ title: SDKs
 description: Official SDKs for building with Model Context Protocol
 ---
 
-Build MCP servers and clients using our official SDKs. All SDKs provide the same core functionality and full protocol support.
+Build MCP servers and clients using our official SDKs. SDKs are classified into tiers based on feature completeness, protocol support, and maintenance commitment. Learn more about [SDK tiers](/community/sdk-tiers).
 
 ## Available SDKs