MCPの仕組み——AIとツールをつなぐ標準プロトコルをわかりやすく解説

MCPはHost・Client・Serverの3層構造で動いてるよ。HostはClaude DesktopやCursorみたいなAIアプリのこと。ClientはそのApp内でMCP通信を担当する部分。ServerはGitHubやSlackなどの外部ツール側が提供するMCPのエンドポイントだよ。

まずHostがMCP Serverに接続して、使えるツール一覧（ツールリスト）を取得するよ。次にユーザーがAIに「GitHubのIssueを見て」と依頼すると、AIはツールリストを参照して適切なMCPツールを呼び出す。Server側が処理して結果を返し、AIがその結果を使って回答するんだ。

以前は各AIと各ツールを個別に連携させる必要があって、nツールとmのAIがあればn×m個のコネクタを書く必要があったんだ。MCPが登場してからは、ツール側がMCPサーバーを一つ作ればすべてのMCP対応AIとつながれる。これをn×m問題の解決と呼ぶよ。

違いを比べてみようか。

比較項目	Function Calling	MCP
接続方式	API経由（HTTP）	標準プロトコル（ローカル/HTTP）
互換性	AIごとに個別実装	どのAIでも同じ仕様
状態管理	ステートレス（基本）	セッション管理あり
認証	各ツールで個別設定	プロトコルレベルで統一
再利用性	低い（AI依存）	高い（標準準拠）

要するにFunction Callingは各AI専用の実装だけど、MCPはどのAIでも動く共通インターフェースだよ。

実は意外と簡単で、Python・TypeScript・JavaなどのSDKが公式で提供されてるよ。SDKを使えば、ツールの定義（何ができるか）を書いてMCPサーバーとして公開するだけ。既存のREST APIをラップしてMCPサーバーに変換する手法も広く使われてるよ。

MCPはOAuth 2.0認証や権限スコープ（何にアクセスできるか）の仕組みを標準で持ってるよ。ユーザーがどのツールへのアクセスを許可するかを明示的に制御できるし、Serverはリクエストを検証してから実行するんだ。完全に信頼できるとは言えないけど、設計段階からセキュリティが考慮されてるよ。