なぜ私たちは96%のトークン節約を拒否したのか

トークンを96%節約できるMCPサーバーを見つけました。それは execute_code という一つのツールを使用します。特定の関数を呼び出す代わりに、エージェントがデータを取得するためにJavaScriptを記述するという仕組みです。

理論上は、それが勝ります。複雑なタスクにおいては、効率性の面でコード実行はツール呼び出しを凌駕します。

しかし、私たちはそれを採用しませんでした。代わりに、個別の名前付きツールを使い続けることにしました。

なぜ、一見明らかな選択が私たちのエージェントにとって間違った選択だったのか、その理由を説明します。

ターゲットが設計を決定する

多くの人は、チャットウィンドウ上のフロンティアモデル向けに構築します。それらのモデルは膨大なトークン予算を持っています。彼らにとって、コード実行こそが至高です。

私たちが構築しているのは、ボート上で動作する、小型のローカルモデル（Hermes 3 8B）を用いた音声優先のエージェントです。

小型モデルにとって、制約はトークンではありません。制約は信頼性です。

小型モデルが単純なツールの呼び出しに苦戦する場合、正しいJavaScriptを書かせることは、はるかに困難なタスクになります。execute_code は信頼性をトークンと引き換えにするものです。私たちには、そのようなトレードオフを行う余裕はありません。

ラストワンマイルの問題

コード実行は、作業の「ラストワンマイル」をエージェントに押し付けます。エージェントは以下の作業を行わなければなりません：

  • データのフィルタリング
  • 結果のソート
  • 出力のフォーマット

私たちのツールは、サーバー内でこれらの作業を行います。例えば、バッテリーの状態について尋ねたとき、私たちのツールはテキスト読み上げ（TTS）の準備が整った文字列を返します。生の数値ではなく、「68パーセント、12.8ボルト」と返します。

もし execute_code を使用すれば、エージェントはその音声をフォーマットするためのロジックを書かなければなりません。小型モデルは、これに常に失敗します。

「不在」のルール

ボートの上では、センサーがオフラインになることがあります。私たちのシステムでは、センサーが見つからない場合はクリーンな null を返します。これは「成功した呼び出し」として扱われます。

コード実行モデルでは、センサーの欠落はしばしばエラーを発生させます。小型モデルが間違ったパスをいくつか推測してしまうと、エラー制限に抵触し、エージェントが停止してしまいます。名前付きツールを使用することで、「不在」をエラーではなく成功として扱うことができるのです。

採用か構築かのチェックリスト

MCPサーバーを採用または構築する前に、以下の質問を自分に投げかけてみてください：

• ターゲットとなるエージェントは誰か？（フロンティアモデルか、小型ローカルモデルか） • 決定的な制約は何か？（トークンか、信頼性か） • ラストワンマイルは誰が担当するか？（ツールがデータをフォーマットするのか、エージェントがするのか？） • 不在をどう扱うか？（値の欠落はエラーか、それとも null か？） • メンテナンスコストはどのくらいか？（休眠状態のコードベースを引き継ぐことになるのではないか？）

私たちはそのプロジェクトを無視したわけではありません。そのアイデアを収穫したのです。彼らのアラーム処理やパス発見ロジックを取り入れ、私たちのロードマップに追加しました。

効率性は素晴らしいものですが、海上においては信頼性が不可欠です。

Source: https://dev.to/clarkbw--/why-we-kept-named-mcp-tools-despite-a-96-token-saving-40ae

Optional learning community: https://t.me/GyaanSetuAi