MCP SDK Tier Audit: modelcontextprotocol/ruby-sdk

SDK: modelcontextprotocol/ruby-sdk
Date: 2026-08-15
Branch: main (commit ad73154, v1.2.0 released 2026-08-15)
Requested tier: Tier 1
Requirements revisions scored: 2025-11-25 and 2026-07-28 (frozen requirement sets, each run at that revision's own wire version, per @modelcontextprotocol/conformance 0.2.0-alpha.11)
Auditor: mcp-sdk-tier-audit skill (tier-check CLI + subagent evaluation)
Previous assessments: Tier 2 (#3127, 2026-07-25); Tier 3 (#2340, 2026-03-03)

Tier Assessment

The Ruby SDK meets every Tier 1 requirement that the deterministic scorecard can measure. Server conformance is 100% (67/67) and client conformance is 100% (50/50) across both frozen requirement sets (2025-11-25 and 2026-07-28), each run at that revision's own wire version. Issue triage compliance is 100% with all 12 required labels present, no P0 has ever been filed, the stable release line is at v1.2.0, the 2026-07-28 spec revision was picked up 4 days after its release (and completed in v1.2.0, 18 days after the spec), and all three required policies (dependency updates, roadmap, versioning) are published and pass. The one item that requires working-group interpretation rather than measurement is the documentation requirement's treatment of the legacy SSE transport (features #39/#40), which the SDK intentionally does not implement: every implemented feature (46/46) is documented with examples. This application requests Tier 1 and poses that question explicitly in Question for the Working Group.

Requirements Summary

Tier Determination

• On the strict count, the determination is Tier 2: 10/11 requirement rows meet the Tier 1 standard, and the only misses are the two legacy-SSE rows (Fix doc example of embedding resources #39/roots/list should not be marked as a client request #40) of the documentation table.
• Every other requirement passes Tier 1 outright: both conformance suites at 100% across both frozen requirement sets, 100% triage with all labels, zero P0s ever filed, a stable v1.2.0 release under a documented versioning policy, a 4-day spec-tracking gap, and all three policies published.
• We request a working-group determination on the documentation scoping question below. If the Tier 1 documentation requirement scopes to implemented features or exempts the superseded transport, the SDK meets Tier 1 in full.
• Tier 1 requirement 4b calls for an implementation timeline agreed per spec release. We propose agreeing that timeline with the spec maintainers as part of this application. The SDK's record on spec tracking: the 2025-11-25 revision was implemented 46 days after the spec release; work on the 2026-07-28 revision started at a 4-day gap and was completed in v1.2.0, 18 days after the spec.

Question for the Working Group

The legacy SSE transport (the 2024-11-05 HTTP+SSE transport) is intentionally not implemented in the Ruby SDK. It was replaced by Streamable HTTP in spec revision 2025-03-26, and the SDK's stable line (v1.0.0, released 2026-07-24) postdates that replacement, so there is no migration constituency to serve. The omission is declared out of scope in ROADMAP.md. TypeScript SDK v2 points the same direction: the SSE server transport was removed from its supported packages and survives only in the frozen, deprecated @modelcontextprotocol/server-legacy migration package (planned for removal in v3), and its client transport is deprecated.

Does the Tier 1 documentation requirement ("comprehensive with examples for all features") scope to implemented features, or otherwise exempt the superseded transport? If yes, the SDK meets Tier 1 in full: the two legacy-SSE rows are the only strict-count misses anywhere in this application, and every implemented feature (46/46) is documented with examples.

Server Conformance Details

Pass rate: 100% (67/67 scored). Revision 2025-11-25: 30/30; revision 2026-07-28: 37/37. The baseline conformance/expected_failures.yml has an empty server list: no known server conformance failures.

Scored - revision 2025-11-25 (30/30)

Scored - revision 2026-07-28 (37/37)

Not scored (run for visibility)

16 additional runs are not part of the frozen requirement sets and are not scored: 10 tasks-* scenarios exercise the SEP-2663 tasks extension, which the SDK intentionally does not implement (tracked in ruby-sdk#391); the remainder are pending scenarios (server-sse-polling, json-schema-2020-12 at the 2026-07-28 wire, http-header-validation, http-custom-header-server-validation) or scenarios added after the revision's release (server-session-lifecycle). Of these, server-session-lifecycle (3/3), json-schema-2020-12 at the 2025-11-25 wire (5/5), and http-header-validation (14/14) pass.

Client Conformance Details

Full suite pass rate: 100% (50/50 scored). Revision 2025-11-25: 18/18; revision 2026-07-28: 32/32. Suite breakdown: Core 11/11 (100%), Auth 39/39 (100%). The http-standard-headers scenario passes 9/9 following the conformance-driver fix in ruby-sdk#514, merged before v1.2.0.

Core Scenarios

Auth Scenarios (scored)

Not scored (run for visibility)

14 additional runs cover extension and added-after-release scenarios, which are not part of the frozen requirement sets. The only failures are auth/dpop, auth/dpop-nonce, and auth/wif-jwt-bearer (at both revisions), all from unimplemented authorization extensions and all documented as the only entries in the conformance/expected_failures.yml client baseline. Extensions are not required for any tier per SEP-1730. The remaining not-scored runs pass, including json-schema-2020-12-preservation (9/9 at both revisions), auth/enterprise-managed-authorization, and both auth/client-credentials-* scenarios.

How to Reproduce

Both conformance legs run against the published conformance CLI with a plain checkout of
modelcontextprotocol/ruby-sdk at main.
Prerequisites: Node.js (for npx) and Ruby with bundle install completed (the SDK's own
conformance CI job uses Ruby 4.0). The numbers in this application were measured with
@modelcontextprotocol/conformance 0.2.0-alpha.11.

# Terminal 1, in the ruby-sdk checkout: start the conformance fixture server.
# One dual-era server serves every revision from the same /mcp endpoint.
bundle exec rake conformance_server

# Terminal 2: server leg, one run per frozen requirement set
npx @modelcontextprotocol/conformance@alpha server --url http://localhost:9292/mcp --requirements 2025-11-25
npx @modelcontextprotocol/conformance@alpha server --url http://localhost:9292/mcp --requirements 2026-07-28

# Client leg, one run per frozen requirement set (no fixture server needed;
# the CLI starts its own scenario servers). Run from the ruby-sdk checkout.
npx @modelcontextprotocol/conformance@alpha client --command "bundle exec ruby conformance/client.rb" --requirements 2025-11-25
npx @modelcontextprotocol/conformance@alpha client --command "bundle exec ruby conformance/client.rb" --requirements 2026-07-28

Each command exits 0 when every scored scenario of that revision's requirement set passes.
Scenarios the set runs without scoring (extensions, additions after the revision's anchor
release) are reported under a separate "Not scored" heading and never affect the exit code.
Append --expected-failures conformance/expected_failures.yml to also assert the recorded
baseline (its server list is empty; its client list carries only the three unimplemented
authorization extensions listed above).

Issue Triage Details

Analysis period: last 3 issues. Labels: all 12 required labels present (bug, enhancement, question, needs confirmation, needs repro, ready for work, good first issue, help wanted, P0, P1, P2, P3); none missing.

Documentation Coverage

46/48 PASS, 0 PARTIAL, 2 FAIL. Core features: 36/36 (100%). The prompt and resource list-changed notification examples were added by ruby-sdk#515. The only FAILs are #39/#40 legacy SSE transport, which is intentionally not implemented (see Question for the Working Group).

Experimental features (informational, not counted): tasks get/result/cancel/list/status-notifications are not implemented (SEP-2663 extension, tracked in ruby-sdk#391).

Tier 1 (all non-experimental features documented with examples): strict FAIL on the two legacy-SSE rows only (#39/#40, intentionally not implemented). Every implemented feature (46/46) is documented with examples.
Tier 2 (basic docs covering core features): PASS, with core features at 36/36 (100%).

Policy Evaluation

1. Dependency Update Policy: PASS

• .github/dependabot.yml is a valid v2 configuration with a weekly schedule.
• Only the github-actions ecosystem is enrolled; bundler is not. Exposure is small: the gem has a single loosely-pinned runtime dependency, json_schemer >= 2.4.

2. Roadmap: PASS

• ROADMAP.md is substantive and explicitly frames itself as the path to SEP-1730 Tier 1.
• It was refreshed by ruby-sdk#519 (merged as commit ad73154, the audited state) and is consistent with the released SDK: it records the 2025-06-18, 2025-11-25, and 2026-07-28 revisions with all scored conformance scenarios passing, records the SEP-2575 lifecycle as shipped during 1.x (dual-era serving), and describes the shipped SEP-2577 deprecation warnings in the present tense. The content cross-checks against the v1.2.0 CHANGELOG entry.

3. Versioning Policy: PASS

• VERSIONING.md covers the versioning scheme, a breaking-change definition with documented exceptions (MCP spec-conformance fixes and security fixes), and how changes are communicated.
• The policy is actively exercised: the v1.2.0 CHANGELOG cites those documented exceptions.

Changes Since the Tier 2 Assessment (#3127)

Remaining Items

1. The working-group documentation-scoping question above (legacy SSE transport, features Fix doc example of embedding resources #39/roots/list should not be marked as a client request #40).
2. Formalizing the per-release implementation timeline agreement (Tier 1 requirement 4b), proposed in the Tier Determination section.

Nothing else is outstanding: both conformance suites pass 100% of scored scenarios with a clean server baseline, no P0 has ever been filed, and all three policies pass at the Tier 1 standard.

cc @felixweinberger @pcarleton