SDK Tiering System - Model Context Protocol Documentation Index Fetch the complete documentation index at: /llms.txt Use this file to discover all available pages before exploring further. Skip to main content Model Context Protocol home page Search... ⌘ K Ask Assistant ⌘ I * Blog * GitHub Search... Navigation Governance SDK Tiering System Documentation Specification Extensions Registry SEPs Community Get Involved * Contributing to MCP * Contributor Communication * Working and Interest Groups * Group Charter Template Shaping the Protocol * Roadmap * Design Principles * SEP Guidelines Governance * Governance and Stewardship * Contributor Ladder * Feature Lifecycle and Deprecation Policy * SDK Tiering System * Security Policy * Antitrust Policy Working Group Charters * Agents Charter * File Uploads Charter * Filesystems Charter * Inspector V2 Working Group Charter * Interceptors Charter * Registry Charter * SDK Working Group Charter * Server Card Charter * Skills Over MCP Charter * Transports Charter * Triggers and Events Charter Interest Group Charters * Authorization Charter * Enterprise Interest Group Charter * Enterprise-Managed Authorization Charter * Financial Services Charter * Primitive Grouping Charter * Security Charter * Tool Annotations Charter On this page * Overview * Tier Requirements * Conformance Testing * Tier Advancement * Tier Relegation * Issue Triage Labels * Type (pick one) * Status (pick one) * Priority (only if actionable) Governance SDK Tiering System Copy page Copy page Feature completeness, protocol support, and maintenance commitment levels for Model Context Protocol SDKs Copy page Copy page 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 and protocol extensions (such as Tasks and 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: * Self-assessing against tier requirements * Opening an issue in the modelcontextprotocol/modelcontextprotocol repository with supporting evidence * Passing automated conformance testing * 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) Was this page helpful? Yes No Feature Lifecycle and Deprecation Policy Security Policy github Assistant Responses are generated using AI and may contain mistakes.