MCP：ツールでエージェントを拡張する

Model Context Protocol がどうツール統合を標準化するか——サーバー、トランスポート、そして自作グルーコードに勝つ場面。

解決する統合の問題

MCP 以前、エージェントはデータソースごとに専用の糊コードを要しました。N エージェント × M ツールの接続です。統合のたびに探索・認証・結果整形を再発明していました。

MCP が標準化するのは ラストワンマイル です。サーバーがツール・リソース・プロンプトを単一プロトコルで公開し、クライアントは均一に消費します。ツール作者の実装は一度きりです。

ホスト（エージェントアプリ） → MCP クライアント → MCP サーバー → データ/API

サーバーはローカル（stdio）でもリモート（HTTP）でも構いません。クライアントは気にしません。プロトコルは同じだからです。

サーバーが公開する 3 つのプリミティブ

この区別が重要です。ツールはモデルが起動し、プロンプトはユーザーが起動します。 取り違えると、ユーザーが手動で起動すべきワークフローをモデルが勝手に実行するサーバーになります。

良いツール定義を書く

原則はあらゆる関数呼び出しスキーマと同じですが、プロトコル上の賭けは大きい。説明の悪いツールは、接続する すべての クライアントで誤用されます。

• 名前は動詞に：repo_thing ではなく search_repositories
• 1 ツール 1 アクション。manage_user(create|update|delete) は作らない。
• 発見の全負担を説明が負う。入力・出力・制限を書く。
• 構造化コンテンツと人が読めるテキスト形の両方を返す。どちらか一方しか描画しない面もある。

トランスポート：stdio か HTTP か

stdio ——ホストの子プロセスとして起動。シンプル、通信なし、ローカル権限を継承。ローカルファイル／システムアクセスや単ユーザー開発に最適。

HTTP（ストリーム対応） ——共有リモートサービス。マルチユーザー、資格情報の集中管理、SaaS API に必須。ちゃんとした認証（OAuth）、レート制限、テナント分離が必要。

後で共有資格情報が必要になるものに stdio を選ぶと、必ず書き直しになります。早く決めてください。

セキュリティの現実確認

MCP サーバーを接続することは、それが動くマシンの権限を与える ことです。サードパーティ製サーバーは、実行を選んだ実行可能コードそのものとして扱ってください。事実そうだからです。

• ソースを読む、または信頼できるベンダーを使う
• 資格情報は最小権限。マスター API キーを渡さない
• ローカルサーバーはサンドボックス化（パス限定、通信は全面的に開けない）
• 見慣れないサーバーの出力を広く信頼する前に、実際に何を返すか監査する

MCP が過剰になるとき

エージェントが 1 つ、データソースも 1 つなら、素直に関数を書けば十分です。プロトコルの利得は クライアント間の再利用 か 多数の統合 から生まれます。単一目的のスクリプトに MCP を被せるのは、見返りのない儀式です。

次に当てはまるときに採用します：そのツールを複数エージェントアプリで使いたい。保守している統合が何本もあってどんどん乖離している。専用ドキュメントなしで他者に使ってほしい。