はじめに
こんにちは、ひるげです。
MCPサーバー、皆さんは使っていますか？
私はClaude Codeで日常的に使ってはいたのですが、「で、MCPって結局何なの？」と聞かれたら説明できない状態が長らく続いていました。
先日、App Store Connect用のMCPサーバー「asc-mcp」を自作してみたところ、MCPの正体がやっと腑に落ちました。
この記事では、その過程で得た「案外単純な中身」と「じゃあ何がすごいのか」という二段階の理解を、自作した実体験ベースでお伝えします。
結論：MCPは「LLM向けの説明書き付きAPIラッパー」+「JSON-RPCによる言語非依存の呼び出し口」
先に、非MCP（従来型 API tool calling）とMCPの比較図を載せておきます。
非MCP（従来型 API tool calling）
MCP
MCP（Model Context Protocol）は、LLMに外部機能を提供するための標準プロトコルです。
実体を分解すると、次の2つの要素でできています。
- LLM向けに説明情報が付加されたAPIラッパー
- JSON-RPCを使った、言語に依存しない呼び出しの仕組み
順に見ていきます。
MCPはAPIのラッパーが9割
作ってみて最初に思ったのが、「MCPってほぼAPIのラッパーだな」ということでした。
MCPサーバーがやっていることは、突き詰めると次の2つだけです。
- 「自分はこういうツールを持っていて、引数はこういう型で、こう使う」という自己記述（ツール定義）を決まった形式で返す
- ツールを呼ばれたら、裏でAPIを叩いて結果を返す
ホスト（Claude Codeなど）は起動時に tools/list というリクエストを投げてツール定義を受け取り、LLMがそれを読んで、自分で判断してツールを呼びます。
つまりMCPは、LLM向けに説明情報が付加されたAPI呼び出しです。
普通のAPIラッパーと違うのは、インターフェースの公開先が人間のプログラマではなくLLMである点だけ。人間向けならドキュメントに書けば済む使い方の説明を、ツール定義のdescriptionに埋め込む必要がある、というわけです。
...ということは、APIが存在するものなら結構お手軽にMCPサーバーを作れそうだな？と気づきます。
実際、かなりサクッと作れました(後述)。
通信はJSON-RPCで統一されている
MCP以前のtool callingでホストが受け取っていた「このツールをこの引数で呼びたい」というJSONは、使っているLLMがOpenAIならOpenAIの、AnthropicならAnthropicの、各社バラバラの独自形式でした。
変わるのは、その意図をホストがMCPサーバーへ実際に送る部分です。ここがJSON-RPC（JSONを使ったリモートプロシージャコール）という共通規格に統一されていて、「このパラメータでこのツール使って」というリクエストを送り、結果を受け取ります。
実際のリクエストは以下のような感じ。
// リクエスト
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"asc_get_sales_report","arguments":{"vendorNumber":"12345678","reportType":"SALES","frequency":"DAILY","reportDate":"2026-07-22"}}}
// レスポンス
{"jsonrpc":"2.0","id":2,"result":{"content":[...]}}
method が呼びたい関数名、params が引数、id はどのリクエストへの返事かの対応づけです。
JSON-RPCで統一されているおかげで、ホストはサーバーの実装言語や中身を一切知らなくても、決まったJSON形式でリクエストを送るだけでツールを使えます。
そしてお気づきでしょうか。
MCPサーバーは、JSON-RPCでのリクエストを受け取り、実際にAPIを叩いた結果をレスポンスとして返す...だからMCPサーバーは、"サーバー"なのです！
何がすごいのか：M×NがM+Nになる
MCPの最大のメリットは、標準化にあります。
ここからは、その標準化がもたらす利点を見ていきましょう。
実は、MCP以前のtool callingでも、LLM自身はコードを実行していません。LLMは昔から「このツールをこの引数で呼びたい」というJSONを出力するだけで、それを受けて実際にAPIを叩くグルーコードは、ホストが書いていました。
- MCP以前: ホストがM個、繋ぎたいAPIがN個あると、M×N通りのグルーコードが必要
- MCP以後: ホストはJSON-RPCを転送する汎用の口を1個ずつ（計M個）、APIはMCPサーバーを1個ずつ（計N個）持てば済む
図にするとこうです。
MCP以前（M×N）
MCP以後（M+N）
MCP以前は、ホストとAPIの組み合わせごとに専用のグルーコードが要るので、線の数（＝実装の数）はM×N本でした。
MCP以後は、ホストとサーバーの間がJSON-RPCという共通規格1本に統一されます。ホスト側はこの共通の口をM個、API側はサーバーをN個実装すればよく、M+Nで済むようになっています。
つまり、MCPが解放したのはこのグルーコードを書いていた開発者なんですね。
グルーコードを第三者がMCPサーバーとして書いて再利用性高く配布できるようになった。私がClaude Code用に作ったasc-mcpを、実際にCodexからも動かしてみましたが、コードは一切変えずに同じツールがそのまま使えました。MCPサーバーをOSS化する価値の根拠もここにあります。
実際に作ってみた：asc-mcp
理解の元になった実物がこちらです。
App Store Connect APIを叩く自分用MCPサーバーで、レビュー取得や売上分析から審査提出、TestFlight管理まで63ツールを扱えるようにしました。
APIが既にあるサービスなら、MCPサーバー化のハードルは本当に低いです。「このAPI、もしかしてMCP化できないかな」と思うものがあれば、ぜひ作ってみてください。
宣伝
最後に少しだけ宣伝をさせてください。
asc-mcpの管理対象でもある、お店開拓アプリ「Roamble」を公開しています。
気になるお店があるのに入れず、結局いつもの店ばかり選んでしまう...という人のためのアプリになっていて、近くのお店がランダムに提案され、実際に訪問するとXPやバッジがもらえる仕組みになっています。
App Storeで公開中なので、興味があればぜひ試してみてください。
ここまで読んでいただきありがとうございました。