MCPのSwift・PHP・Kotlin SDKは今どこまで使えるか
MCP公式SDKのうちTier 3の3言語(Swift・PHP・Kotlin)の実装範囲とバージョンを、リリース情報から具体的に確認します。
Swift・PHP・KotlinのMCP SDKは何が違うか
MCPの公式SDKは10言語に提供されており、Swift・PHP・KotlinはいずれもTier 3(実験的、または部分実装)に分類されています。ただし3言語の実態は一様ではありません。KotlinはマルチプラットフォームでTypeScript SDK並みに機能が揃っている一方、PHPはSymfonyプロジェクトとの協業で始まったばかりの若いSDKです。Tierの数字だけでは実装の厚みまでは分かりません。
3言語に共通するのは、パッケージのバージョンがまだ1.0に届いていない点です。Swiftは0.12系、PHPは0.8系、Kotlinは0.15系で、いずれも安定版(1.0以降)を宣言していません。これはSDK Tiering Systemが要求する「Stable Release」基準(Tier 1は明確なバージョニング付きの安定版が必須、Tier 2は最低1回の安定版が必須)を、3言語ともまだ満たしていないことと整合します。Tierの判定基準そのものはMCP SDK Tierシステムとはで扱っています。
3言語のスペック早見表
| 項目 | Swift | PHP | Kotlin |
|---|---|---|---|
| 最新バージョン | Swift0.12.1 | PHP0.8.1 | Kotlin0.15.0 |
| 対応プラットフォーム | SwiftApple各OS、Linux(glibc/musl) | PHPPHP(Composer) | KotlinJVM・Native・JS・Wasm |
| 最小要件 | SwiftSwift 6.0+ | PHPPHP 8.1+ | KotlinKotlin 2.2+、JVMは11+ |
| 主導組織 | SwiftAnthropic | PHPPHP Foundation・Symfony | KotlinAnthropic |
| 実装方式 | Swiftクラスベース | PHPPHP 8 Attribute(#[McpTool]) | Kotlinコルーチンベース |
いずれも公式リポジトリの最新タグ・パッケージ情報にもとづく値です。バージョンは更新が速いため、実装前に各パッケージマネージャー(Swift Package Manager・Packagist・Maven Central)で最新値を確認してください。
3言語の中でPHP SDKだけは、Conformance Tests(適合性テスト)の合格率をREADME上のバッジとして公開しています。仕様バージョンごとにサーバー適合率・クライアント適合率のバッジが分かれており、自動更新されるバッジとして公開しています。Tier 3のSDKに数値の公開義務はありませんが、PHP SDKは自主的にこの透明性を確保しています。Swift・Kotlinの2言語には同種のバッジはREADME上に見当たりません。
Swift SDK — Appleプラットフォーム前提の実装
Swift SDKはSwift 6.0以上を要求します。対応プラットフォームはmacOS 13以降・iOS/Mac Catalyst 16以降・watchOS 9以降・tvOS 16以降・visionOS 1.0以降の全Appleプラットフォームです。加えて、glibcまたはmuslベースのLinuxディストリビューション(Ubuntu・Debian・Fedora・Alpineが名指しされています)にも対応しています。「Apple製アプリ組み込み用」という印象だけで見ると見落としがちですが、サーバー側をLinux上で動かし、クライアント側だけAppleプラットフォームのアプリに組み込む構成も選べます。
クライアント・サーバー双方の実装に加え、OAuth 2.0の認可コードフロー・クライアント資格情報フロー・カスタムトークンプロバイダーまで、認証まわりの実装がREADME上でも厚く書かれているのが特徴です。
一方で、対応しているMCP仕様バージョンは2025-11-25で、最新の2026-07-28版ではありません。ドキュメント内のトランスポート説明の一部にも2025-06-18版の仕様ページへのリンクが残っており、仕様追従はTier 1のTypeScript・Pythonより1〜2版遅れています。Apple製アプリにMCPクライアント・サーバーを組み込む用途では現実的な選択肢ですが、最新仕様の機能(たとえば新しい認可フローの細部)を前提にする実装では、対応状況を個別に確認する必要があります。
PHP SDK — Symfonyの設計思想を引き継いだ若いSDK
PHP SDKはPHP FoundationとSymfonyプロジェクトの協業で開発されており、Symfonyのコーディング規約と後方互換性ポリシーを踏襲しています。最初のメジャーリリースまでは公式に「実験的」と位置付けられており、これがTier 3の分類とも一致します。
要求バージョンはPHP 8.1以上です。実装はPHP 8のAttributeが中心で、メソッドに#[McpTool]、#[McpResource(uri: "...")]を付けるだけでサーバーの機能として公開され、Server::builder()->setDiscovery(...)がディレクトリ内のクラスを自動検出します。3言語の中では最も宣言的で書く量が少ない設計です。
Tier 3という分類にもかかわらず、周辺エコシステムはすでに動き始めています。公式READMEには、API PlatformのMCP統合、Drupalの設定・エンティティ公開モジュール、CakePHPプラグイン、Symfony公式のAIアシスタントMCPサーバーなど、主要PHPフレームワーク向けの実装が一覧として掲載されています。「実験的」という一語だけを見ると採用に慎重になりがちですが、周辺ライブラリの数はすでにひとつの目安になります。
3言語の中で唯一、最新のプロトコル改訂(2026-07-28、ステートレス方式の追加)への対応をREADMEで明記しているのもPHPです。Tier 3で仕様追従が最速という組み合わせは、Tierが機能の新しさではなく適合率(conformance)・対応SLA・保守コミットメントを測る指標であることを裏付けています。
Kotlin SDK — Tier 3の中では機能が最も厚い
KotlinはKotlin Multiplatformを採用し、JVM・Native・JS・Wasmの4ターゲットを単一コードベースでサポートします。アーティファクトはクライアント専用・サーバー専用・両方を含む統合アーティファクト(umbrella)の3種に分かれており、Ktorをトランスポート実装に使うためKtorのエンジン依存だけ自分で追加する構成です。
機能面では、prompts・resources・tools・completion・logging・pagination(サーバー側)、roots・sampling(クライアント側)が揃っており、対応トランスポートもstdio・Streamable HTTP・SSE・WebSocketの4種と、Tier 1のTypeScript SDKに引けを取りません。capabilities一覧の表にはelicitation(構造化入力のダイアログ表示)もクライアント機能として記載されていますが、README内の該当セクションは「TODO: add elicitation section」というコメントのまま本文が書かれておらず、ドキュメント整備が機能実装に追いついていない箇所として残っています。Tier 3の要件では文書化の最低ラインが設けられていないため、この状態自体はTierの規定に反しているわけではありません。
導入コマンドの違い
3言語ともパッケージマネージャーからの導入は数行で済みますが、書き方の作法は言語ごとに異なります。
Swiftはパッケージマネージャーで依存を宣言する方式です。
dependencies: [
.package(url: "https://github.com/modelcontextprotocol/swift-sdk.git", from: "0.12.1")
]PHPはComposerでインストールし、Attributeを付けたクラスをそのままサーバーとして起動します。
composer require mcp/sdkKotlinはMaven Centralのアーティファクトをビルドスクリプトに追加します。クライアント専用・サーバー専用・統合アーティファクト(umbrella)のどれを使うかで参照するアーティファクト名を変えます。
dependencies {
implementation("io.modelcontextprotocol:kotlin-sdk-server:$mcpVersion")
implementation("io.ktor:ktor-server-netty:$ktorVersion") // トランスポートに使うKtorエンジンは自分で選ぶ
}Kotlinだけがトランスポートのエンジン(Ktor)を利用側で選ぶ設計になっている点は、他の2言語と違う癖として覚えておく価値があります。エンジンを変えればNettyの代わりにCIOやJettyも選べる一方、依存関係の宣言を1行削っただけでビルドが通らなくなる典型的なつまずきにもなります。
Claude Codeから見て何が変わるか
Claude Codeは接続先のMCPサーバーがどの言語・どのTierのSDKで実装されているかを区別しません。stdioまたはHTTPのトランスポートでJSON-RPCメッセージを正しくやり取りできれば、Tier 3のSDKで書かれたサーバーでも通常どおり接続できます。実務上の判断が必要になるのは、自分でサーバーを実装する側の選択です。
Apple製アプリへの組み込みが前提ならSwiftの選択肢は他に代えがたく、PHPは既存のSymfony/Laravel資産があるチームで自然な選択になります。Kotlinはマルチプラットフォーム対応の広さから、Android・デスクトップ・サーバーサイドを横断するプロジェクトで検討する価値があります。逆に、Tierの数字だけを見て「Kotlinは実験段階だから機能が乏しい」と判断するのは早計です。機能の網羅性とTierの数字は別の軸で動きます。
まとめ
Swift・PHP・KotlinはTier 3という同じ分類でも、実態は「Appleプラットフォーム特化で仕様追従がやや遅いSwift」「若いが最新仕様に追従が早いPHP」「機能は厚いがドキュメントの一部が未整備なKotlin」と、それぞれ異なる制約を抱えています。選定では、Tierのバッジよりもバージョン番号(いずれも1.0未満)・対応プラットフォーム・実装が要求する言語バージョンを個別に確認するほうが、実装後の手戻りを防げます。Java・C#・Goを含む10言語全体のTier一覧と選び方の基準はMCP SDK Tierシステムとは、TypeScript・Pythonでの実装手順はMCPサーバー自作ガイドを参照してください。