この記事は Model Context Protocol の成功から話を始める。今や開発者は、数十の MCP サーバーにまたがる数百から数千のツールにアクセスできるエージェントを日常的に構築している。記事は、その規模では 2 つのよくあるパターンがエージェントを遅く、高コストにすると論じる。ほとんどの MCP クライアントはすべてのツール定義を最初からコンテキストウィンドウに読み込むため、数千のツールに接続されたエージェントは、リクエストを読む前に数十万トークンを処理することになりかねない。また、ツールの中間結果はすべてモデルを経由するため、あるツールで取得して別のツールで書き込む文書は、コンテキストを 2 回通過することになる。
記事が提案する答えは、MCP サーバーを直接のツール呼び出しとしてではなくコードの API として提示し、エージェントにコード実行環境の中でそれらを呼び出すコードを書かせることである。これは、この wiki が Code Execution MCP として記録しているアプローチである。そうすればエージェントは、必要なツールだけを読み込み、結果をモデルに返す前に実行環境の中でデータを処理できる。
要点
- 最初から読み込まれたツール定義はコンテキストウィンドウの領域を占有し、応答時間とコストを増やす。
- モデルを経由する中間結果はトークンを消費し（記事の例では、2 時間の営業会議の文字起こしで約 50,000 トークンが余分にかかるとされる）、コンテキストの上限を超えうるうえ、ツール呼び出し間での転記ミスを起こりやすくする。
- ある実装では、接続されたサーバーのファイルツリーを生成し、ツールごとに 1 つの TypeScript ファイルで基盤となる MCP 呼び出しをラップする。エージェントはディレクトリを一覧してツールを見つけ、必要なファイルだけを読む。
- 記事の例では、これによってトークン使用量が 150,000 から 2,000 に減り、記事はこれを時間とコストの 98.7% の削減だと説明している。
- Cloudflare も「Code Mode」という名前で同様の知見を公表したと報告されている。共通する洞察は、LLM はコードを書くのが得意であり、エージェントはその強みを MCP サーバーとのやり取りに活かすべきだ、というものである。
- ツール定義は段階的開示（Progressive Disclosure）の一形態として必要に応じて読み込むことも、
search_toolsツールを通じて見つけることもできる。このツールの詳細度パラメーターによって、エージェントは各定義をどこまで読み込むかを選べる。 - 大きな結果はコードの中でフィルタリング、集約、結合できるので、エージェントは例えば 10,000 行のスプレッドシートのすべてではなく 5 行だけを見ることになる。
- ループ、条件分岐、エラー処理は、エージェントループを通じたツール呼び出しの連鎖としてではなくコードとして実行でき、これは「最初のトークンまでの時間」のレイテンシーの削減にもなる。
- 中間結果はデフォルトで実行環境の中にとどまり、ハーネスは個人情報のような機微なデータをモデルに届く前にトークン化し、別のツールに渡すときにトークン化を解除できる。そのため、実際の値はモデルのコンテキストに一度も入ることなくシステム間を流れる。
- ファイルシステムへのアクセスにより、エージェントは状態を永続化し、動作するコードを再利用可能な関数として保存できる。そうした関数に
SKILL.mdファイルを加えると、それらは Agent Skills の概念と結びつく。 - コード実行にはそれ自体のコストがある。エージェントが生成したコードを実行するには、適切なサンドボックス化、リソース制限、監視を備えた安全な実行環境が必要であり、記事はこれらのコストを利点と比較して検討すべきだとしている。
背景
この記事は MCP を立ち上げた組織である Anthropic によって書かれており、その数値は実測した研究ではなく同社自身の説明用の例に基づいている。記事は、自らが扱う問題（コンテキスト管理、ツールの組み合わせ、状態の永続化）を、ソフトウェアエンジニアリングにすでに解決策があり、コード実行がそれをエージェントに適用するものだと位置づけ、実装者に対して MCP コミュニティと知見を共有するよう呼びかけている。コンテキストウィンドウを無駄なく保つことへの関心は、この wiki のコンテキストエンジニアリングに関する記述とつながっている。