Apideck CLI：AIエージェント向けMCPの低コンテクスト代替手段

MCPのコンテキストウィンドウ問題

この記事では、特定のシナリオが説明されています：GitHub、Slack、SentryをMCPサーバー経由で接続する（合計約40ツール）と、エージェントが単一のユーザーメッセージを処理する前に55,000以上のトークンを消費します。これはClaudeの200k制限の4分の1以上に相当します。各MCPツール定義は、その名前、説明、JSONスキーマ、フィールド説明、列挙型、およびシステム指示のために550〜1,400トークンを消費します。

あるチームは、3つのMCPサーバーが200,000トークンのうち143,000トークン（コンテキストウィンドウの72％）を消費し、実際の会話、取得されたドキュメント、推論、および応答のために残り57,000トークンしか残っていないと報告しました。

Duetを構築しているDavid Zhang（@dzhng）は、「三すくみ」のためにMCP統合を完全に削除したと説明しました：すべてを事前に読み込んで作業メモリを失う、統合を制限してエージェントが少数のサービスとしか通信できないようにする、または動的ツール読み込みを構築してレイテンシとミドルウェアの複雑さを追加する。

ベンチマーク結果

Scalekitによるベンチマークでは、75回の直接比較（同じモデル：Claude Sonnet 4、同じタスク、同じプロンプト）が行われ、以下の結果が得られました：

• 同一の操作に対してMCPはCLIよりも4倍から32倍多くのトークンを消費する
• リポジトリの言語を確認するのに、CLIでは1,365トークン、MCPでは44,026トークンを消費した
• オーバーヘッドはほぼ完全にスキーマによるもの：すべての会話に43のツール定義が注入され、そのうちエージェントが使用するのは1つか2つだけ

Apideck CLIのアプローチ

Apideck CLIは、数万トークンのスキーマを置き換える約80トークンのエージェントプロンプトを使用します。--helpによる段階的開示と、バイナリに組み込まれた構造的安全性を特徴としています。シェルコマンドを実行できるエージェントは、プロトコルサポートを必要とせずにそれを使用できます。

コンテキスト肥大化に対する業界の対応

この記事では、業界の3つのアプローチを特定しています：

• 圧縮トリックを使用したMCP： スキーマを圧縮し、ツール検索を使用して定義をオンデマンドで読み込む、またはOpenAPI仕様を小さなチャンクに分割するミドルウェアを構築する。これは小さく明確に定義された相互作用には有効ですが、インフラストラクチャの必要性（ツールレジストリ、検索ロジック、キャッシング、ルーティング）を追加します。
• CLIファーストインターフェース： Apideck CLIが採用しているアプローチ。
• エージェントネイティブプロトコル： 提供されたソーステキストでは言及されていますが詳細は記載されていません。