コアポイント
Anthropicのエンジニアがコミュニティで指摘：ほとんどの人はMCPの表面しか使っていない。
ほとんどの開発者のMCPに対する理解はここで止まっている：
「MCPサーバーに接続 → 関数を呼び出す → 結果を取得」
この「ツール呼び出し」パターンはMCPの能力の最も浅い層に過ぎない。MCPの真の価値はこれをはるかに超えている。
MCPの3層能力モデル
第1層：ツール呼び出し（ほとんどの人が留まる場所）
エージェント → MCPサーバー → ツール呼び出し → 結果返却これが現在90%の開発者の使い方。MCPサーバーに接続し、関数を呼び出し、結果を取得する。有用だが、到底十分とは言えない。
第2層：リソースサブスクリプションとストリーミング
MCPはツールだけでなくリソースの概念をサポートしている：
- 静的リソース：ファイル、データベースレコード、設定情報
- 動的リソース：リアルタイムデータストリーム、ログ、モニタリング指標
- リソースサブスクリプション：エージェントはリソースの変更をサブスクライブでき、毎回能動的にクエリする必要がない
これはエージェントが繰り返しポーリングする必要がなく、受動的に更新を受信できることを意味し、長期実行エージェントシナリオにおいて重要。
第3層：コンテキスト管理と動的発見
MCPの深い能力：
- プロンプト注入：MCPサーバーはエージェントにシステムレベルのプロンプトを注入し、利用可能な能力と使用制約を通知
- 動的発見：エージェントは実行時に新しいツールや能力を動的に発見、事前に定義する必要がない
- マルチサーバー協調：複数のMCPサーバー間でコンテキストとリソースを共有可能
見落とされている高価値用法
| 用法 | 現在の採用率 | 価値レベル |
|---|---|---|
| 基本ツール呼び出し | 90%以上 | 基本 |
| リソースストリーミングサブスクリプション | 約15% | 高 |
| 動的ツール発見 | 約10% | 極めて高い |
| マルチサーバーコンテキスト共有 | 約5% | 極めて高い |
| プロンプト注入と自己記述 | 約20% | 高 |
実際の例：MCPは単なる「天気チェック」ではない
データベースクエリMCPサーバーがあるとしよう：
基本用法：エージェントが query_database 関数を呼び出し、SQLを渡して結果を取得。
高度な用法：
- MCPサーバーがプロンプトを注入し、データベーススキーマ、インデックス、クエリ制限をエージェントに通知
- エージェントが特定のテーブルの変更イベントをサブスクライブ、データ更新時に自動通知
- MCPサーバーがクエリの複雑さに基づいて最適な実行戦略を自動選択
- 複数のMCPサーバーがクエリキャッシュを共有、重複計算を回避
アクション提言
- 既存のMCPユーザー：MCPサーバーがリソースとプロンプトを有効にしているか確認。ツールだけでなく
- MCPサーバー開発者：リソースサブスクリプション機能の追加を検討。エージェントが「能動的にポーリング」ではなく「受動的に待機」できるように
- エージェントフレームワークユーザー：OpenClaw、HermesなどのフレームワークがMCPリソースサブスクリプションと動的発見をサポートする進展に注目
- アーキテクト：MCPをエージェントと外部システムの汎用通信層として捉える。単純な関数呼び出しインターフェースではなく
まとめ
MCPは「ツール呼び出しプロトコル」から「エージェント・システム通信インフラ」へと進化している。早期にその深い能力を理解し採用することで、エージェントアプリケーションアーキテクチャにおいて顕著な優位性を築ける。