これは、コンテキスト エンジニアリングについてさらに詳しく学びたい学生にとって、必読の記事です。 この記事では、MCPツールが多すぎるという問題を解決する方法について説明します。エージェント開発に携わり、多くのMCPツールを使用した経験のある人なら誰でも、MCPツールが多すぎることの最大の問題は、コンテキストを過度に消費することであり、これはコストの増大につながるだけでなく、推論と生成の品質にも影響を与えることをご存知でしょう。 もう 1 つの問題は、MCP ツールによって返される中間結果も大量のコンテキスト スペースを消費することです。 この記事を読んでいると、Manusを称賛せずにはいられませんでした。彼らは確かにコンテクスチュアルエンジニアリングを深く探求しており、彼らが共有しているエンジニアリング手法は、彼らが以前に共有してきたものと非常によく似ています（以前共有したManus関連の記事も後ほどコメント欄に投稿します）。 Anthropic のアプローチも非常にシンプルで直接的です。つまり、「コード」をツールとして扱い、コードから MCP を呼び出します。 これを行うと多くの利点があります: 1. システムプロンプト内のツール定義が多すぎる問題を解決しました。 システム プロンプトですべての MCP ツールをロードする必要はありません。1 つの「コード」ツールのみを定義する必要があります。 ツールが必要になったらどうすればいいでしょうか? このコードはすべて統合ディレクトリに保存されています。ディレクトリ内を検索することで適切なツールを見つけることができます。例えば、この記事のディレクトリの例を以下に示します。 サーバー ├── Googleドライブ │ ├── getDocument.ts │ ├── …（その他のツール） │ └── index.ts ├── セールスフォース │ ├── updateRecord.ts │ ├── …（その他のツール） │ └── index.ts └──…（他サーバー） 必要なツールが見つからない場合はどうすればいいでしょうか? 今すぐ書いてください！保存して次回も使えます。 2. MCP ツールから返される結果が長すぎる問題を解決しました。 例えば、MPCツールを使用して10,000行のデータを取得し、それらをフィルタリングして変換し、適切なデータを取得したい場合、まずコードからMPCツールを呼び出して10,000行のデータを取得し、次にコードからフィルタリングして、最終的に5つのデータエントリのみを返します。このようにすることで、コンテキストは、以前のように10,000個のデータエントリを保持するのではなく、フィルタリングされた5つのデータエントリのみを保持すれば済みます。 3. データプライバシーの問題を解決しました。 MCPツールを直接使用する場合、ツールから返されるデータは毎回コンテキストにロードし、LLMにアップロードする必要があります。コードを使用して、機密データをコンテキストに追加する前に2回処理することができます。 4. 中間成果の持続とスキルの蓄積 このコードは、中間結果をファイルに書き込んでハードドライブに保存することができます。これはコンテキスト空間を占有しない一方で、MCPを繰り返し呼び出すことを避けるために、いつでもハードドライブから中間結果を保存することができます。 さらに、コードの多くは一時的に生成されますが、この一時的に生成されたコードは「スキル」として保存・蓄積することができます。SKILL.MDファイルの追加により、Claude Codeのスキルと同様に、繰り返し再利用することが可能です。
