【ITニュース解説】There is no official C++ SDK for MCP. So we wrote one — and ran it through the official conformance suite

データインフラの世界では、データベース、ゲームエンジン、組み込み機器、金融システム、高性能コンピューティングなど、あらゆる場所でC++というプログラミング言語が使われている。これらのシステムが日々扱う大量のデータを、異なるシステム間で効率的かつ標準的な方法でやり取りするために「MCP（Model Context Protocol）」という通信規約が注目され、多くの企業がこれを採用しようとしている。しかし、MCPプロトコルを利用するための公式なソフトウェア開発キット（SDK）は、TypeScript、Python、C#、Go、Rust、Ruby、Java、Swift、PHP、Kotlinといった様々な言語向けに提供されているものの、肝心のC++向けは存在しなかった。この状況は、C++を基盤とする多くのシステム開発者にとって大きな課題であった。

この課題を解決するため、開発者たちは独自にC++向けのMCP SDKである「mcp-cpp」を開発した。このSDKはC++17という比較的新しいバージョンのC++に対応し、2026年7月28日付けのMCPプロトコル仕様に準拠している。mcp-cppは、複雑な非同期処理のためのランタイムを必要とせず、JSONを扱うためのシンプルなヘッダファイル一つと、必要に応じて利用できるHTTPライブラリ一つだけで構成されているため、既存のC++プロジェクトに容易に組み込むことが可能だ。プロジェクトのビルド設定ファイルにfind_package(mcp CONFIG)と記述するだけで、このSDKを利用できるようになる。これは、開発者がより本質的なアプリケーションロジックに集中できることを意味する。

mcp-cppが対応している2026年7月28日付けのMCP仕様は、以前の2025年版から大幅な変更が加えられている。例えば、従来の「初期化ハンドシェイク」や「セッションID」といった概念は廃止され、全ての通信リクエストは、そのリクエストがどのプロトコルバージョンに対応しているか、そしてクライアントがどのような機能を持っているかを示すメタ情報を自身の中に含んで送られるようになった。また、サーバーは自身が提供するサービスをserver/discoverという仕組みで公開し、クライアントがそれを発見する形をとる。重要な点として、サーバーが一方的にクライアントにリクエストを送信することはなく、サーバーが何らかの追加情報を必要とする場合は、「入力が必要である」という応答を返し、クライアントがその要求に応じて再試行するという「MRTR（Multiple Round Trip Request）」という仕組みが導入された。さらに、リアルタイムでの更新情報は「サブスクリプション」を通じて提供される。

mcp-cppは、これらの最新仕様の全てを網羅している。サーバー機能としては、Builderというツールを使ってサービスを構築でき、ツールやリソース、プロンプトなどを定義できる。これには、URLのパターンを柔軟に指定できるRFC 6570スタイルのURIテンプレートも含まれる。また、特定のクライアントが特定の機能を利用できるかを制御する「機能ゲーティング」や、データの改ざんを防ぐための署名付きリクエスト状態管理（HMAC-SHA256という暗号技術を使用）、処理の進捗をクライアントに通知する機能、進行中の処理をキャンセルする機能、そしてキャッシュ可能な結果の管理機能も提供する。クライアント機能としては、処理が完了するまで待機する「ブロッキング」方式と、データの意味を重視した「値セマンティック」な処理が可能で、MRTRの自動履行機能により、クライアントはサーバーからの追加入力要求を自動的に処理して再試行できる。また、ユーザー認証やサービス連携を安全に行うための業界標準である「OAuth 2.1」クライアント機能も完全に実装されており、関連する多くのRFC（標準規格）やSEP（仕様拡張提案）に対応している。通信方法としては、標準入出力（stdio）と、データストリームとして扱えるHTTP（Streamable HTTP）の両方をサポートしている。HTTP通信では、MCPプロトコルバージョンやメソッド名、パラメータなどを示す特別なヘッダがミラーリングされ、これらが厳格に検証される。また、複数のメッセージをストリームとして送信するSSE（Server-Sent Events）レスポンスや、過去のサーバーとの互換性を保つためのGETリスニングストリーム、そして接続が切断された際に自動的に再接続する機能も備わっている。データ検証機能も充実しており、JSON Schema 2020-12という強力なスキーマ検証ツールが組み込まれている。これにより、サーバーが受け取る入力データや、クライアントに返す出力データが、あらかじめ定義されたスキーマに準拠しているかどうかが常にチェックされ、不正なデータのやり取りを防ぐ。

実際に、mcp-cppを使ってシンプルなサーバーを構築する例は非常に簡潔だ。以下に示すようなコードで、二つの整数を受け取り、その合計を返すサーバーをわずか15行で実装できる。

Copy
1#include <mcp/mcp.hpp>
2#include <string>
3
4int main() {
5mcp::server::Builder b;
6b.name("my-server").version("1.0");
7b.tool(mcp::Json(R"({"name":"add","description":"adds two integers",
8"inputSchema":{"type":"object","properties":{"a":{"type":"integer"},
9"b":{"type":"integer"}},"required":["a","b"]}})"),
10[](mcp::server::Ctx& c) -> mcp::McpResult<mcp::Json> {
11const mcp::Json args = mcp::member(c.params, "arguments");
12const int64_t sum = mcp::member(args, "a").toInt64() +
13mcp::member(args, "b").toInt64();
14mcp::Json out(R"({})");
15out.add("sum", mcp::Json(sum));
16return mcp::Ok(mcp::server::structuredResult(out,
17"sum = " + std::to_string(sum)));
18});
19mcp::StdioTransport t;
20return b.build()->run(t).has_value() ? 0 : 1;
21}

このコードでは、まずmcp::server::Builderを使ってサーバーの基本的な情報を設定し、「add」という名前のツール（機能）を定義している。このツールは、inputSchemaでaとbという二つの整数を必須の入力として受け取ることを指定し、それらの合計を計算して「sum」という名前で結果を返す。最後にmcp::StdioTransportを使って標準入出力経由での通信を設定し、サーバーを起動している。このシンプルさは、開発の効率性を大幅に向上させる。

mcp-cppの信頼性は、単に開発者が「問題ない」と言うだけでなく、MCPプロトコルの公式な適合性テストスイート（modelcontextprotocol/conformance）を通じて検証されている。このテストスイートは、他の公式SDKが利用しているものと同じであり、mcp-cppは2026年7月28日仕様のサーバーとクライアントの両方の役割で、全てのテスト項目において100%の合格率を達成した。2025年版の仕様では一部不合格の項目があるが、これは2026年版で廃止された古い仕組みを実装しないという開発方針によるものか、またはテスト環境自体に存在するバグが原因であり、mcp-cppの欠陥ではないことが説明されている。

実際に適合性テストを実行する過程で、mcp-cpp自体にいくつか潜在的なバグが発見され、それらは迅速に修正された。例えば、HTTP通信中に通知が適切に処理されない問題や、古い仕様のサーバーとの通信でエラーが発生する問題、JSON-RPCエラー応答の解析に関する問題、セッションIDの競合、HTTPヘッダの空文字列の扱いに関する問題などだ。これらのバグは、テストスイートという客観的な評価ツールがあったからこそ発見され、修正できたものであり、mcp-cppの品質向上に大きく貢献した。さらに、このテストの過程で、公式テスト環境のモック（仮想的な相手システム）にもバグがあることを発見し、その証拠と共に公式に報告している。これは、mcp-cppが厳密な検証を経ていることの証でもある。

mcp-cppの設計思想には、C++特有のいくつかの工夫が凝らされている。まず、C++17というバージョンを選択したのは、既存のC++インフラで広く利用されているGCC 9やMSVC v142といったコンパイラとの互換性を重視したためだ。これにより、多くの開発者が容易にmcp-cppを導入できる。また、プロトコル層は「値セマンティック」に基づき、例外処理を一切使用しない設計となっている。これは、McpResult<T>という特定の型を使って処理の成功・失敗を明示的に表現し、[[nodiscard]]属性を使って戻り値の確認を強制することで、より堅牢で予測可能なコードを目指している。さらに、セキュリティに不可欠な暗号技術（HMAC-SHA256やPKCEなどの乱数生成）は、外部のライブラリに依存せず、mcp-cpp内部で実装されている。これにより、不必要な依存関係を避け、プロジェクトの複雑性を低減している。サーバーのディスパッチ（リクエストを適切なハンドラに振り分ける処理）は、基本的にシングルスレッドでステートレスに動作するように設計されている。これは、データベースの操作やORM（オブジェクト関係マッピング）サーバーのような、個々のリクエスト処理が比較的重い場合に、システム全体のボトルネックがループ処理ではなくハンドラ自体にあるという考えに基づいている。最後に、ドキュメントは英語と中国語の両方で提供されており、幅広い開発者コミュニティへの貢献を目指している。

mcp-cppは既に実用段階に入っており、zorm-mcpというプロダクション環境で動作するMCPサーバーのプロトコル層として利用されている。このサーバーは、sqlite3、jsonfile、mysql、postgres、dm8といった異なるデータベースに対応し、それらを一つの統一されたインターフェースで操作できるORM（オブジェクト関係マッピング）であるzormを支えている。これは、mcp-cppが単なるプロトタイプではなく、実際のビジネスニーズに応える堅牢なSDKであることを証明している。

今後のロードマップとしては、OAuthサーバー側の認証強化、ログ出力の補助機能、データ解析のパフォーマンス向上（ゼロコピー解析パスの実装）、そしてパッケージマネージャーであるvcpkgやConanへの対応、詳細なドキュメント生成ツールのDoxygen対応などが計画されている。開発者たちは、git cloneとcmakeコマンドで簡単にmcp-cppを試すことができ、Linux、macOS、Windowsの主要なコンパイラ（gcc, clang, MSVC）環境での継続的な統合テストも実施されている。

開発者たちは、mcp-cppを試用し、意見やバグ報告をGitHubのリポジトリに寄せることを強く推奨している。そして何よりも、C++がMCPプロトコルの公式SDKリストに加わるべきだと考えるのであれば、MCP SDKワーキンググループのような影響力のある場所でその声を上げてほしいと呼びかけている。公式の適合性テストをクリアし、継続的な統合テストが緑（全て合格）であるリポジトリ、そして実際に利用されているユーザーが存在し、明確な依存関係ポリシーを持つmcp-cppは、公式SDKとして認められる準備が整っていると言えるだろう。mcp-cppのソースコードはMITライセンスで公開されており、GitHubで誰でも確認できる。