Claude Media
MCP SDK Tierシステムとは — SDKを選ぶ前に確認すべき基準
Claude CodeMCP解説

MCP SDK Tierシステムとは — SDKを選ぶ前に確認すべき基準

MCP公式SDKのTier 1〜3を分ける判定基準と、10言語それぞれの現在地を一覧で示します。

読了目安 約11分

MCP SDK Tierシステムとは何か

MCP SDK Tierシステムは、Model Context Protocolの公式SDKを機能の完成度・仕様追従の速さ・保守コミットメントでTier 1〜3に分類する制度です。運用するのはSDK Working Groupで、SDKごとのIssue対応期限やConformance Tests(適合性テスト)の合格率といった数値基準で評価し、昇格と降格はグループの合意で決めます。

どの言語のSDKが本番導入に足り、どれが実験段階なのかは、このTierで見分けます。MCPそのものの仕組みはMCP実用ガイド、個別言語の実装手順はJavaでMCPサーバーを書く手順、Tier 3の3言語の実態はMCPのSwift・PHP・Kotlin SDKは今どこまで使えるかで扱っています。

10言語の現在地

2026-07-28版の公式SDK一覧にあるTierと、各言語のパッケージレジストリの最新版です。

言語Tier最新版
TypeScriptTierTier 1最新版1.32.0
PythonTierTier 1最新版2.3.0
C#TierTier 1最新版2.2.0
GoTierTier 1最新版v1.8.0
RustTierTier 1最新版3.5.0
RubyTierTier 1最新版1.6.1
JavaTierTier 2最新版2.0.1
SwiftTierTier 3最新版0.12.1
PHPTierTier 3最新版0.8.1
KotlinTierTier 3最新版0.15.0
数字

Tierごとの言語数

  • Tier 1

    6言語

    TypeScript・Python・C#・Go・Rust・Ruby

  • Tier 2

    1言語

    Java

  • Tier 3

    3言語

    Swift・PHP・Kotlin

Tier 1と2の7言語は、いずれも1.0以降の安定版を出しています。Tier 3の3言語は0.x台です。安定版リリースはTier 1・2の要件で、Tier 3では求められません。バッジを見なくても、バージョン番号からおおよその成熟度は読めます。

最新版はレジストリで直接引けます。バージョンは日々動くので、実装の直前にこの方法で取り直すのが確実です。以下はnpm・PyPI・Goのモジュールプロキシ・RubyGemsに問い合わせる例で、出力が上の表の値になります(Rustのrmcp、Javaのmaven-metadata.xmlなども同じ要領で引けます)。

npm view @modelcontextprotocol/sdk version
curl -s https://pypi.org/pypi/mcp/json | python3 -c 'import sys,json;print(json.load(sys.stdin)["info"]["version"])'
curl -s https://proxy.golang.org/github.com/modelcontextprotocol/go-sdk/@latest | python3 -c 'import sys,json;print(json.load(sys.stdin)["Version"])'
curl -s https://rubygems.org/api/v1/gems/mcp.json | python3 -c 'import sys,json;print(json.load(sys.stdin)["version"])'
1.32.0
2.3.0
v1.8.0
1.6.1

どのSDKを選ぶか

Tierの数字を実装判断に落とすなら、次の3つを順に確かめます。

手順

SDK選定の3問

  1. 1

    本番の可用性要求は

    24時間稼働のサービスに組み込むなら、重大バグが7日以内に直るTier 1が安心材料です。Tier 2は重大バグの解消が2週間以内、Tier 3は要件なしです。社内ツールや検証目的なら、この差を許容できるかで選べます。

  2. 2

    言語やプラットフォームに縛りはあるか

    Apple製アプリ、既存のPHP/Symfony資産、Kotlin Multiplatformのような制約がある場合は、Tierより言語が優先されます。Tier 3でも選ばざるを得ないケースです。

  3. 3

    新しい仕様の機能に依存するか

    標準の機能(sampling・elicitationなど)は、Tier 1が新仕様リリースの前に、Tier 2が6か月以内に対応する約束です。新仕様の機能を公開前後から使いたい場合は、リリース前の対応を約束するTier 1が対象になります。Tier 3には対応期限のコミットがないので、機能追加を待つ前提の設計は避けたほうが安全です。

3つ目には注意点があります。TasksやMCP Appsのような実験的機能とプロトコル拡張は、どのTierでも実装を求められません。「Tier 2以上ならTasksに対応している」とは言えず、使いたい拡張があるなら、そのSDKのドキュメントとリリースノートで個別に確かめることになります。

Tierを分ける8つの基準

評価項目は8つあります。うち5つは数値で表せるので下表にまとめ、残りは表の下で説明します。

基準Tier 1Tier 2Tier 3
Conformance Tests合格率Tier 1100%Tier 280%Tier 3下限なし
新仕様への対応期限Tier 1新仕様リリースの前Tier 26か月以内Tier 3コミットなし
Issueの一次対応Tier 12営業日以内Tier 21か月以内Tier 3要件なし
重大バグの解消Tier 17日以内Tier 22週間以内Tier 3要件なし
安定版リリースTier 1明確なバージョニング必須Tier 2最低1回必須Tier 3不要

Tier 1の対応期限は固定の日数ではなく、リリースごとに機能の複雑さを見て合意する形です。Tier 1の定義自体も、sampling・elicitationのような任意機能まで含めた、実験的でない全機能の実装です。Tier 2は「完全対応に向けて保守されているSDK」にあたります。

「安定版」は1.0.0以降で、-alpha・-beta・-rcのようなプレリリース識別子が付かないバージョンです。Tier 1が求める「明確なバージョニング」は、言語の慣習に沿った番号付けと、破壊的変更の方針を文書にしておくことを指します。

数値化しにくい3項目は、次のとおりです。

  • ドキュメント: Tier 1は全機能に実例付きの網羅的な説明、Tier 2は中核機能をカバーする基本的な説明を求められます。Tier 3に最低ラインはありません。
  • ロードマップ: Tier 1は公開ロードマップが必須です。Tier 2は、Tier 1への到達計画かTier 2に留まる理由の説明を出します。
  • 依存ポリシー: Tier 1・2はともに公開された更新ポリシーが必須で、Tier 3は不要です。

Conformance Testsが数えている範囲

Conformance Testsは、公式のconformanceリポジトリが提供する自動テストスイートです。プロトコルメッセージのやり取りが仕様どおりかを検証します。合格率の分母は無条件の全テストではなく、次の4種類が除外されます。

  1. SDKが対応を宣言していない仕様バージョン向けのテスト
  2. pendingまたはskippedとマークされたテスト
  3. 実験的機能向けのテスト
  4. 旧仕様との後方互換性を検証するレガシーテスト(SDKが互換性維持を掲げている場合を除く)

加えて、conformanceリポジトリ側でdisputedラベルが付いたテストは、判定が決着するまで集計から外れます。

この除外のおかげで、対象外の仕様バージョンや実験的機能のテストで落ちて不当に低いスコアになる事態は避けられます。裏返すと、合格率100%は「実装した範囲では仕様どおり」という意味で、仕様全体の実装済みを保証しません。実装範囲の広さはSDKのドキュメントとリリースノートで別に見ます。

Issue対応の速さはどう測るのか

Issue対応期限を計測するため、すべてのSDKリポジトリに共通のラベル運用が求められます。ラベルは3種類です。

  • Type(1つ選ぶ): bug(動かない)・enhancement(新機能の要望)・question(情報の請求)。GitHubのネイティブIssue Typeを使っていればラベルは不要です。
  • Status(1つ選ぶ): needs confirmation(まだ関係があるか不明)・needs repro(再現情報が足りない)・ready for work(着手できる情報がある)・good first issue・help wanted
  • Priority(対応が必要な場合のみ): P0(致命的)・P1(多数に影響する重大な不具合)・P2(中程度の問題、価値ある要望)・P3(あれば嬉しい程度、まれなエッジケース)

「一次対応」はラベル付けとIssueの有効性判断で、解決そのものではありません。計測の起点にも癖があります。一次対応は「Issue作成から最初のラベルまで」、重大バグの解消は「P0ラベルからIssueのクローズまで」を測ります。つまりTier 1の7日は、P0と判断された時点から数え始めます。

共通ラベルは名前まで統一されているので、各SDKのリポジトリでP0やneeds reproの付いたIssueを絞り込めば、制度の計測と同じ軸で対応の速さを自分でも見られます。

P0の定義は2つです。CVSSスコア7.0以上(High〜Critical)のセキュリティ脆弱性と、接続確立・メッセージ交換・コア機能(tools・resources・prompts)の利用を止める障害です。

Tierは降格もする

Tierは一方通行ではありません。最新の安定版でConformance Testsが4週間連続で落ち続けると、降格されることがあります。Tier 1はテストが1件でも失敗した時点でTier 2へ、Tier 2は失敗率が20%を超えた時点でTier 3へ移る条件です。Issue対応が2か月間放置された場合も降格されることがあります。

上げたいときの手順は4段階です。

手順

Tier昇格の申請

  1. 1

    自己評価

    自分のSDKをTierの要件と照らし合わせます。

  2. 2

    Issueで申請

    modelcontextprotocol/modelcontextprotocolリポジトリにIssueを立て、根拠を添えます。

  3. 3

    Conformance Testsに合格

    自動テストを通します。

  4. 4

    Working Groupの承認

    SDK Working Groupのメンテナーが承認し、最終的なTierが決まります。

誰がどこまで決めているのか

Tierを運用するSDK Working Groupの担当は6つです。他のグループとの役割分担はMCPのWorking Group・Interest Group一覧 — 17グループの役割分担にまとめています。

  • Tierの運用(昇格の審査、降格の適用、公開済みTierの維持)
  • 公式SDK一覧の管理(新規追加・廃止の審査)
  • Tier 1向けのリリース計画を仕様のリリース日に合わせる調整
  • SDK間の設計パターンの共通化
  • Conformance Testingプロジェクトとの連携
  • SDKメンテナー同士の情報交換の場づくり

担当外も明記されています。個別SDKのIssue対応・PRレビュー・リリース、仕様そのものの策定(SEPプロセスで進める)、テスト自体の作成、modelcontextprotocol組織の外にあるサードパーティSDKは、このグループの管轄ではありません。

くらべる

決定権限の2階層

個別のTier

Working Groupの合意だけで決まる

SDKのTier昇格・降格は、グループの合意で決まります。メンバーは、SDK Working Groupに属する各SDKのメンテナー全員です。

制度そのもの

Core Maintainersの承認も要る

Tierの判定基準を変えるとき、公式SDKを追加または廃止するときは、グループの合意に加えてCore Maintainersの承認が必要です。

Core Maintainersに至る道のりはMCPコントリビューターラダーの全体像 — メンバーからコアメンテナーへで扱っています。

メンバーは公式SDKのメンテナーです。憲章の成功基準は、全SDKにTierが付いていることと、既定ブランチでConformance Testsが通っていることです。昇格・降格の判断は、理由つきでGitHub Discussionsに記録する決まりです。

あゆみ

Tier制度が動き出すまで

  1. 2026-01-23Conformance Testsが利用可能に

    公式のテストスイートが使えるようになり、メンテナーは標準ラベルの運用とテストの導入に着手できました。

  2. 2026-02-23Tier付けが一般に公開

    制度の公式版が公開されました。それまでの1か月は、メンテナーがテストとラベル運用を導入する移行期間でした。

  3. 2026-04-28SDK Working Groupの憲章が初版に

    担当範囲と決定権限が文書化されました。作業項目には、四半期ごとのTier見直しが入っています。

まとめ

Tierは、本番の可用性要求と必要な言語から逆算して見る指標です。バッジの数字だけでなく、レジストリの最新版と、使いたい拡張機能に対応しているかを合わせて確かめると、実装後の手戻りを避けやすくなります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →