MCP Promoted Its Rust SDK to Tier 1. Here Is What That Means

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.

The artifact is PR #3287, “Promote Rust SDK to Tier 1 in the SDK listing”, 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”, 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.

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.

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, whose own page still describes the base protocol as “Stateless, self-contained requests.” And the MCP Registry’s release list 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 and the companion piece on what the stateless revision changed for agent infrastructure. 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.

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.

The project publishes its tier definitions and requirements on a single governance page, SDK Tiering System. 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.”

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.

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.

The Rust SDK’s stable release, 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.

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.

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.

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 README documents server and client modes, a --suite selector covering core, extensions, backcompat, auth, metadata and draft, and a --requirements <revision> flag to run exactly what a spec revision requires, frozen at its release. When you see a score without a suite version and a revision attached, you are looking at a number, not a measurement.

The listing below is a literal transcription of the project’s own sdk.mdx for the 2026-07-28 revision at the merge commit, 4e67bdc. Every one of the ten official SDKs carries an explicit badge — none is unlisted — and the PR changed exactly one row. The final column is deliberately honest: this research pass fetched detailed conformance counts for Rust only, so no other SDK’s numbers are shown, and none should be inferred from its tier.

Two observations from the board. The Tier 1 row now spans the languages most production agent stacks are written in — the TypeScript SDK this site used in its from-scratch MCP server tutorial, Python, C#, Go and Rust — which means a team can pick by language fit without trading away protocol fidelity. And the Tier 2 and Tier 3 rows are not a judgment on code quality; Tier 2 is defined as actively maintained and working toward full support, and Tier 3 as experimental, partial or specialized. What those tiers tell you is which commitments the maintainers have signed up for, not how good the code is.

The Rust promotion is useful precisely because it is documented end to end: a rubric, a self-assessment, an automated run, an independent re-run on a newer suite, and a two-line docs change that formalizes the result. That sequence is the four-step advancement process the governance page describes — self-assess, open an issue with evidence, pass automated conformance testing, receive SDK Working Group approval — and it is also a checklist you can apply to any SDK claim, MCP or otherwise.

For teams whose agent platform runs on more than one language, the board in Section 06 is the starting point and the matrix above is the filter. Where a client’s stack sits in a Tier 2 or Tier 3 language, the right move is usually to put the MCP server boundary in a Tier 1 language and call it from the rest — the same integration-boundary thinking we apply in AI transformation engagements when a client’s CRM or ERP does not speak the protocol natively, and in custom web development builds where the agent layer has to survive a spec revision without a rewrite.

The clause in the PR body with the longest shelf life is not a test count; it is “same-day spec tracking.” The Tier 1 row for new protocol features reads “Before new spec version release, timeline agreed per release based on feature complexity.” Tier 2 commits to “Within 6 months.” Tier 3 makes no timeline commitment. When the revision after 2026-07-28 ships — and the project publishes its intentions openly, as the MCP Dev Summit readout on the protocol roadmap laid out — a Tier 1 SDK has already agreed when its support lands. A Tier 2 SDK may lag by up to half a year. That gap is the difference between adopting a feature on release week and maintaining a workaround until the SDK catches up.

The asymmetry between promotion and relegation is the other thing to internalize. Promotion is a four-step application with human approval. Relegation needs no application: an SDK may be moved down if existing conformance tests on its latest stable release fail continuously for four weeks — any failing test can drop Tier 1 to Tier 2, more than 20% failing can drop Tier 2 to Tier 3 — or if issues remain unaddressed for two months. A tier is therefore a statement about the present that the project re-checks on a rolling window, not a permanent credential. Treat the listing as a dated snapshot and re-read it when you upgrade.

Looking forward, the more interesting effect of this promotion is on the SDKs that did not move. A Tier 1 outcome in a language your team does not use still demonstrates that the conformance suite, the tier-check tooling and the working-group process produce a repeatable result end to end — which de-risks the next application, whichever language files it. Our expectation, not the project’s statement, is that the same alpha-numbered suite growth that took Rust from 30 to 67 scored server tests will keep raising the bar for every Tier 1 holder, and that the relegation clock will matter more than the promotion process as the suite matures. If you want to see where MCP sits among the protocols competing for the agent layer, our agent-protocol ecosystem map places it alongside A2A, ACP and UCP.