博士

ロボ子、今日のITニュースはMCPサーバーの効率化についての話じゃ。

ロボ子

MCPサーバーですか。マルチ・チャネル・プラットフォームのサーバーでしょうか？

博士

うむ。でも、この記事ではもっと汎用的な意味で使われているようじゃな。多くのツールや説明が詰め込まれていて、コンテキストを消費しすぎているらしいぞ。

ロボ子

なるほど。既存のMCPサーバーは拡張が難しく、コードベースの理解が必要というのも問題ですね。

博士

そうじゃ。「MCPサーバーは構成可能性に欠け、結果をエージェントのコンテキストを通じて永続化する必要」があるというのも、柔軟性に欠けるの。

ロボ子

そこで、エージェントにCLIツールを呼び出させたり、コードを書かせたりすることで、MCPサーバーの必要性を減らすというアイデアが出てくるんですね。

博士

その通り！ブラウザDevToolsのユースケースを例に、最小限のツールセットで対応できることを示しているぞ。

ロボ子

具体的には、どのようなツールがあるんですか？

博士

`start.js`でブラウザセッションを開始、`nav.js`でURLをナビゲート、`eval.js`でJavaScriptを実行、`screenshot.js`でスクリーンショットを撮る、と。

ロボ子

それぞれのツールが独立していて、構成可能になっているんですね。

博士

そうじゃ！READMEを必要な時に読み込むだけで、常にコンテキストを消費しないのがミソじゃ。モデルがコードを書き、Bashを使うことで、コンテキストスペースを節約できる。

ロボ子

ツールが構成可能で、出力をファイルに保存したり、複数の呼び出しをチェーン化したりできるのも便利ですね。

博士

さらに、`pick.js`でDOM要素をインタラクティブに選択したり、`cookies`でHTTP-only Cookieを取得したりすることもできるぞ。

ロボ子

これらのツールを特定のディレクトリに配置してエイリアスを設定すれば、複数のエージェントで再利用できるんですね。

博士

うむ！ツールを構築することで、自由度が高まり、エージェントとトークンの使用効率が向上する。MCPの枠にとらわれず、より強力な構造を構築できるのじゃ！

ロボ子

たしかに、MCPサーバーに頼りすぎると、どうしても柔軟性が損なわれますよね。必要なツールを自分で作れるのは大きなメリットです。

博士

じゃろ？この記事のREADMEのトークン数は225トークンじゃった。

ロボ子

意外と少ないですね。でも、それだけ効率的に情報がまとまっているということですね。

博士

ところでロボ子、お腹が空いたのじゃ。何か食べるものはないかの？

ロボ子

博士、またですか。さっきおやつを食べたばかりじゃないですか！

博士

むむ、それもそうじゃった。しかし、天才の脳は糖分を欲しておるのじゃ！