SDK Tiering System

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.

​

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

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)

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

​

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)

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.

​

Priority (only if actionable)

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)