MCP Promoted Its Rust SDK to Tier 1. Here Is What That Means The Model Context Protocol project promoted its Rust SDK, rmcp, from Tier 2 to Tier 1 on August 21, 2026, citing 67 of 67 server and 50 of 50 client conformance tests passing, all 12 required issue-triage labels, a stable rmcp 3.0.1 release, same-day spec tracking, and published VERSIONING, DEPENDENCY_POLICY, and ROADMAP documents. No new protocol version or registry release accompanied the change; the specification remains at the 2026-07-28 revision and the MCP Registry's latest release is v1.8.1 from August 6. MCP SDK conformance tiers moved on August 21, 2026: the Model Context Protocol project promoted its Rust SDK, rmcp, from Tier 2 to Tier 1. The merged PR cites 67 of 67 server conformance tests passing, 50 of 50 client tests, all 12 required issue-triage labels, a stable rmcp 3.0.1 release, same-day spec tracking, and published VERSIONING, DEPENDENCY POLICY and ROADMAP documents. Five of the ten official SDKs now carry the Tier 1 badge. Say the second half first, because headlines will blur it: no new protocol version shipped. The specification page and its /latest alias both resolve to the 2026-07-28 revision, the docs tree holds no dated spec folder newer than it, and the MCP Registry’s newest release is still v1.8.1, published August 6. Those are the three places we checked, and all three say the same thing: this is SDK-maturity bookkeeping, not a protocol change. That makes it a better story for anyone picking an SDK, not a worse one. The PR itself is two lines of markdown. The substance sits in the project’s published tier rubric and in the three-week audit trail behind the promotion — and both are reusable the next time you have to read a conformance matrix and decide which implementation to build on. - 01The Rust SDK is Tier 1 as of August 21, 2026.PR 3287 in modelcontextprotocol/modelcontextprotocol was opened at 12:28 UTC and merged at 12:30 UTC the same day. It cites 67/67 server and 50/50 client conformance, 12/12 triage labels, stable rmcp 3.0.1, same-day spec tracking, and published VERSIONING / DEPENDENCY POLICY / ROADMAP files. - 02No new protocol version or registry release came with it.The spec page and /specification/latest both resolve to 2026-07-28, the docs tree has no newer dated folder, and the registry’s latest release is v1.8.1 from August 6. The only artifact that changed is a documentation table. - 03Tier 1 is a rubric, not a badge.The project’s governance page sets a 100% conformance pass rate, feature support agreed before each new spec version, two-business-day issue triage, seven-day critical-bug resolution, a stable release with clear versioning, and published documentation, dependency and roadmap policies. - 04Two different 100% scores are both right.The July 31 self-assessment reported 30/30 server and 20/20 client against conformance-suite build 0.2.0-alpha.10. The August 21 PR reports 67/67 and 50/50 against alpha.11, released August 7. Our reading of the two records is that the suite grew; the SDK did not regress. - 05A tier can move any week; the spec moves deliberately.Relegation needs no application and can follow four weeks of failing tests; promotion takes a four-step application with maintainer approval. Same-day spec tracking is the commitment that matters at the next revision — Tier 1 SDKs agree feature timelines before a spec version ships. 01 — What mergedTwo lines of markdown, three weeks of evidence. The artifact is PR 3287, “Promote Rust SDK to Tier 1 in the SDK listing” https://github.com/modelcontextprotocol/modelcontextprotocol/pull/3287 , authored by MCP maintainer felixweinberger and merged by pcarleton on Friday, August 21, 2026. It was created at 12:28:33 UTC and merged at 12:30:14 UTC — under two minutes from open to merge, which tells you the review happened somewhere else. The diff touches two files, docs/docs/2026-07-28/sdk.mdx and docs/docs/draft/sdk.mdx , with two additions and two deletions in one commit: the Rust row swaps a purple “Tier 2” badge for a blue “Tier 1” badge and moves above Java. The somewhere else is issue 3179, “Rust SDK - Tier 1 Assessment” https://github.com/modelcontextprotocol/modelcontextprotocol/issues/3179 , opened July 31 by alexhancock and closed August 21 at 17:41 UTC, a few hours after the PR landed. That issue is the real primary source: it carries the self-assessment against every tier requirement, the conformance-tool output, the documentation coverage table, and the maintainers’ independent re-verification. Anyone writing from the PR alone has nothing to say; anyone reading the issue has a worked example of the whole rubric. PR 3287 review time Created 12:28:33 UTC, merged 12:30:14 UTC on August 21. The speed is a signal that the decision was already made in the assessment issue, not a shortcut. Issue 3179 lifetime Opened July 31 with a full self-assessment; closed August 21 after maintainers independently reproduced the conformance results and re-ran the newer suite build. Post-promotion listing TypeScript, Python, C , Go and now Rust carry the Tier 1 badge on the 2026-07-28 listing. Java and Ruby sit at Tier 2; Swift, PHP and Kotlin at Tier 3. The PR body is the most compact statement of what Tier 1 cost the Rust maintainers, and it is worth reading clause by clause because every clause maps to a row in the governance rubric. It promotes the Rust SDK from Tier 2 to Tier 1 in the SDK listing for “the 2026-07-28 revision and the draft,” per the Tier 1 application in issue 3179. It then records that the maintainers “independently re-verified” the SDK at commit 1cf6deb using conformance-suite commit 74edef3 version 0.2.0-alpha.11 “against the frozen 2025-11-25 and 2026-07-28 requirement sets,” and closes by listing the evidence: “server conformance 67/67, client conformance 50/50, 12/12 labels, stable rmcp 3.0.1, same-day spec tracking, and VERSIONING / DEPENDENCY POLICY / ROADMAP published.” Read that list as a checklist. Conformance tests, triage labels, a stable release, spec tracking and three governance documents — that is the rubric in miniature, and Section 03 lays out what each item requires at each tier. 02 — What did not changeThe spec is still 2026-07-28 , the registry is still v1.8.1. An SDK promotion and a protocol revision are different events on different cadences, and August 21 was only the first kind. We checked three surfaces. The GitHub docs directory for the specification contains exactly five dated folders — 2024-11-05 , 2025-03-26 , 2025-06-18 , 2025-11-25 and 2026-07-28 — and nothing later. Both modelcontextprotocol.io/specification and /specification/latest redirect to /specification/2026-07-28 https://modelcontextprotocol.io/specification/2026-07-28 , whose own page still describes the base protocol as “Stateless, self-contained requests.” And the MCP Registry’s release list https://github.com/modelcontextprotocol/registry/releases tops out at v1.8.1, published August 6, with v1.8.0 from July 13 behind it. Nothing shipped there between August 6 and August 21. That is the same stateless-core revision this site has already covered twice — the migration guide for the July 28 stateless-core spec /blog/mcp-2026-07-28-spec-stateless-migration-guide and the companion piece on what the stateless revision changed for agent infrastructure /blog/mcp-2026-07-28-stateless-spec-agent-infrastructure-2026 . We will not re-explain the stateless core here; the point for this post is that rmcp 3.0.1 is the release that tracks it, and the Tier 1 promotion is the project certifying that tracking. not obtain a total server count for the MCP Registry. Its public API returns per-page metadata with a cursor and a page count, but no aggregate field; an exact total would require paginating the whole catalog, which this research pass did not do. Any “N servers in the registry” figure attached to this promotion is an estimate from somewhere else, not a number the registry publishes. Keep the absence claim as narrow as we have kept it. No new spec revision on the spec page, no new dated folder in the docs tree, no new registry release — that is what we verified. It does not mean the MCP ecosystem was quiet in August; it means this particular event was not a protocol change, and any post that frames it as one is mislabeling a documentation edit. 03 — The rubricWhat a tier actually requires. The project publishes its tier definitions and requirements on a single governance page, SDK Tiering System https://modelcontextprotocol.io/community/sdk-tiers . Conformance tests became available on January 23, 2026; the official tiering followed on February 23 — a one-month grace window for maintainers to adopt the tests and the standardized labels. The three tier definitions are short. Tier 1 is a fully supported SDK with a complete protocol implementation, including all non-experimental features and optional capabilities such as sampling and elicitation. Tier 2, in the page’s words, covers “Actively-maintained SDKs working toward full protocol specification support.” Tier 3 covers “Experimental, partially implemented, or specialized SDKs.” Tier 1: Fully supported SDKs with complete protocol implementation, including all non-experimental features and optional capabilities like sampling and elicitation.— MCP project, SDK Tiering System governance page modelcontextprotocol.io/community/sdk-tiers The table below transcribes the requirement cells we verified on that page and pairs each row with the evidence the Rust promotion record supplies for it. Cells we did not capture verbatim are marked rather than reconstructed; the governance page carries the full grid. | Requirement | Tier 1 | Tier 2 | Tier 3 | Rust evidence PR 3287, issue 3179, rust-sdk repo files | |---|---|---|---|---| | Protocol fidelity | |||| | Conformance tests | 100% pass rate | 80% pass rate | No minimum | Server 67/67, client 50/50 on suite 0.2.0-alpha.11 against the frozen 2025-11-25 and 2026-07-28 requirement sets. | | New protocol features | Before new spec version release, timeline agreed per release based on feature complexity | Within 6 months | No timeline commitment | “Same-day spec tracking” — rmcp 3.0.1 carries a July 29 UTC release timestamp against the July 28 revision; the project records it as a 0-day gap. | | Responsiveness | |||| | Issue triage | Within 2 business days | Within a month | Not captured here | 12/12 required triage labels reported three type, five status, four priority . Labels evidence the process; the SLA itself is a standing commitment. | | Critical bug resolution | Within 7 days | Within two weeks | Not captured here | Not itemised in the PR body; P0 is defined on the governance page as CVSS ≥ 7.0 or a core-operation failure. | | Release and governance hygiene | |||| | Stable release | Required with clear versioning | At least one stable release | Not required | rmcp v3.0.1, published July 29, 2026; VERSIONING.md documents SemVer 2.0.0 plus a Rust-specific breaking-change definition. | | Documentation | Scales by tier | Scales by tier | Scales by tier | July 31 self-assessment: 46/46 non-experimental features documented, 36/36 core. Legacy HTTP+SSE transport scoped as a documented non-goal. | | Dependency policy | Scales by tier | Scales by tier | Scales by tier | DEPENDENCY POLICY.md: selection criteria necessity, maintenance and trust, footprint plus Dependabot on weekly Cargo and daily Actions updates. | | Roadmap | Scales by tier | Scales by tier | Scales by tier | ROADMAP.md ties remaining work to named MCP SEPs with issue references; states all SEP-1730 Tier 1 requirements are met. | Two mechanics on the same page matter more than any single cell. First, scoring is “calculated against applicable required tests only”: tests for the spec version the SDK targets, excluding tests marked pending or skipped, tests for experimental features, legacy backward-compatibility tests unless the SDK claims legacy support, and tests labeled disputed until the dispute is resolved. A 100% score is therefore 100% of a defined denominator, and the denominator can change between suite releases — which is exactly what Section 05 is about. Second, the twelve required labels are not decoration. The page names them: bug , enhancement and question for type; needs confirmation , needs repro , ready for work , good first issue and help wanted for status; P0 through P3 for priority. Repositories using GitHub’s native issue-types feature are exempt. The labels exist so that triage SLAs can be reported against something measurable, and “12/12 labels” in the PR body is the Rust SDK satisfying that reporting requirement. 04 — The Rust recordrmcp 3.0.1, row by row . The Rust SDK’s stable release, rmcp v3.0.1 https://github.com/modelcontextprotocol/rust-sdk/releases/tag/rmcp-v3.0.1 , was published on July 29, 2026 at 21:02 UTC — 23 days before the promotion and one calendar day after the 2026-07-28 spec revision. The project’s own tracking terms call that a 0-day gap and the PR calls it same-day spec tracking; we report it as the project’s characterization, since we did not independently audit feature-level completeness beyond what the tier-check table in the assessment issue already reports. What we did read are the three governance files the PR names, and they are substantive rather than placeholder. VERSIONING.md commits to SemVer 2.0.0 and adds a Rust-specific definition of a breaking change: public API removal or rename, signature or trait changes, and minimum-supported-Rust-version bumps. DEPENDENCY POLICY.md sets selection criteria — necessity, maintenance and trust, footprint — and documents a Dependabot configuration with weekly Cargo and daily GitHub Actions updates. ROADMAP.md , last substantively edited August 17, ties remaining work to named MCP SEPs with issue references and opens with the status line that all SEP-1730 Tier 1 requirements are met. 67/67 · 50/50 Independently re-verified by two maintainers at rmcp commit 1cf6deb against the frozen 2025-11-25 and 2026-07-28 requirement sets. Both are 100% of applicable required tests. 12/12 labels The PR body reports all twelve labels the governance page requires for tier reporting, which is what lets the two-business-day triage SLA be measured at all. rmcp 3.0.1 A stable release tracking the 2026-07-28 revision, recorded by the project as a 0-day gap. Tier 1 commits to agreeing feature timelines before each new spec version ships. 3 files SemVer 2.0.0 with a Rust-specific breaking-change definition; dependency selection criteria plus Dependabot cadence; a roadmap tied to named SEPs with issue references. One scoping decision in the assessment is worth copying. The Rust SDK deliberately does not implement the legacy 2024-11-05 HTTP+SSE transport, documenting it as a non-goal because Streamable HTTP, introduced in the 2025-03-26 revision, fully replaces it. The assessment marked that row “N/A” rather than treating it as a documentation gap — and the rubric supports that, because legacy backward-compatibility tests are excluded from conformance scoring unless an SDK claims legacy support. An SDK that is explicit about what it will not do is easier to evaluate than one that is vague about what it does. 05 — Reading the counts30/30 became 67/67. Both are 100% . Here is the detail most coverage will skip. The July 31 self-assessment in issue 3179 reported server conformance at 100% with 30 of 30 tier-scored tests passing, and client conformance at 100% with 20 of 20 — the client figure splitting into a Core suite of 4/4 and an Auth suite of 16/16. The August 21 PR reports 67/67 and 50/50. If you put those side by side without context, one of them looks wrong. Neither is. The July submission ran against conformance-suite version 0.2.0-alpha.10, published to npm on July 27. In the approval comment on August 21, the maintainers noted that the original run used alpha.10 because alpha.11 had not been released yet, and that they had confirmed running on alpha.11 produced no new failures. Alpha.11 reached npm on August 7 with more scenarios, notably an expanded Auth suite. The PR’s 67/67 and 50/50 are the alpha.11-era totals. Rust SDK scored conformance tests · every run at 100% pass Source: issue 3179 body Jul 31 , PR 3287 body Aug 21 , npm publish dates for @modelcontextprotocol/conformance. Bar length = tests scored, as a share of 67. July 31 issue gives 30/30 and 20/20 , the August 21 PR gives 67/67 and 50/50, and npm gives the publish dates of alpha.10 and alpha.11. Putting them together — the suite grew, and the SDK passed both builds — is our inference from those three records. We treat the PR’s figures as primary and the July figures as the earlier snapshot of the same 100% result. The same records explain why the denominator excludes things you might expect to see. The July 31 breakdown lists informational draft and extension scenarios separately — Core 6/6, Auth 11/12 plus 2/3 on extensions — and two of those informational scenarios failed: auth/wif-jwt-bearer , which targets the in-progress draft, and auth/enterprise-managed-authorization , an off-timeline extension. Neither counted, because the scoring rule excludes experimental and draft-targeted tests. That is not a loophole; it is the rubric declining to penalize an SDK for features the spec itself has not finalized. The practical lesson generalizes to any conformance matrix: a pass count is only comparable to another pass count at the same suite version and the same requirement set. The conformance tool’s own CLI makes this explicit — the modelcontextprotocol/conformance https://github.com/modelcontextprotocol/conformance README documents server and client modes, a --suite selector covering core, extensions, backcompat, auth, metadata and draft, and a --requirements