SDK Tiering System

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.

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.

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 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), giving users visibility into upcoming feature support.

Conformance Testing

All SDKs are evaluated using automated conformance tests 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)
• Excluding tests labeled disputed in the conformance repository, until the dispute is resolved

Conformance testing validates that SDKs correctly implement the protocol by running standardized test scenarios and checking protocol message exchanges. See 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 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

An SDK may also be relegated if issues remain unaddressed for two months.

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 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)