ハクソク

世界を動かす技術を、日本語で。

CLIを通じてMCPをより安価にする

89日前原文(kanyilmaz.me)

概要

  • MCP 利用エージェントは、ツールカタログの読込で 余計なコスト を支払う構造
  • CLI は、必要最小限の情報のみを初回読込し、詳細は オンデマンド取得 でコスト削減
  • CLI 方式は、トークン消費量で 最大94%削減 可能
  • Anthropic Tool Search も効率化だが、CLIにはコスト面で及ばず
  • CLIHub でCLIsのディレクトリ・自動生成ツールを OSS提供

MCPとCLIのトークンコスト比較

  • MCP は、全ツールの JSON Schema を初回セッションで一括読込
    • 例： 84ツール × 185トークン = 15,540トークン
  • CLI は、ツール名・場所のみの 軽量リスト を読込
    • 例： 6 MCPサーバー × 50トークン = 300トークン
  • CLI は、詳細情報を必要な時だけ --helpコマンド で取得
  • MCP は、ツール呼び出し自体は低コスト（定義済み情報活用）
  • CLI は、初回呼び出し時に コマンドリファレンス全体 を取得するが、総量では圧倒的に低コスト

具体的なトークン消費例

  • セッション開始時
    • MCP：約 15,540トークン
    • CLI：約 300トークン
  • 1ツール利用時
    • MCP：約 15,570トークン
    • CLI：約 910トークン
  • 10ツール利用時
    • MCP：約 15,840トークン
    • CLI：約 964トークン
  • 100ツール利用時
    • MCP：約 18,540トークン
    • CLI：約 1,504トークン
  • CLIは常に90%以上のトークン削減

Anthropic Tool Searchとの比較

  • Anthropic Tool Search は、 検索インデックスのみを初回読込 し、必要時に詳細取得
    • セッション開始時：約 500トークン
    • 1ツール利用時：約 3,530トークン
    • 10ツール利用時：約 3,800トークン
    • 100ツール利用時：約 12,500トークン
  • CLI はAnthropic Tool Searchより 40～88%低コスト
  • Anthropic Tool Search はAnthropic専用、 CLIはモデル非依存

CLIHubの意義

  • CLIHub は、多数のツール用CLIを 集約・提供 するOSSディレクトリ
  • MCPサーバーからCLIを自動生成 するコンバータもOSS公開
  • Openclawのavailable_skills形式 を採用し、他形式にも柔軟対応
  • CLIHub活用で、 エージェント開発のコスト・手間を大幅削減

まとめ

  • MCP方式 は、ツールカタログの全読込で 非効率なトークン消費
  • CLI方式 は、 オンデマンド取得 により 圧倒的なコスト削減
  • CLIHub などOSSを活用することで、 効率的なエージェント運用 が可能

Hackerたちの意見

へへ…いいね！みんな同じこと考えてると思う。俺も https://mcpshim.dev を立ち上げたよ（https://github.com/mcpshim/mcpshim）。ユニックス方式が一番だね。

└

いいね！両方比べてみたけど、要するに CLIHUB は MCP サーバーをポータブルで自己完結型のバイナリにコンパイルするツールだよ。コンパイラみたいなもんだね。配布や CI、デーモンを動かせない環境に最適。mcpshim はランタイムブリッジで、ローカルプロキシみたいな感じ。特に LLM エージェントと組み合わせると、持続的な接続や軽量エイリアスが活きるから、ローカルで複数の MCP サーバーを扱う開発者には最高だよ。--- https://cdn.zappy.app/b908e63a442179801e406b01cf412433.png（比較表） ---

└

これ、数週間前に見た気がするか、似たようなやつ。https://github.com/philschmid/mcp-cli 編集: スレッドの別のところで指摘されてたけど、実際はhttps://github.com/steipete/mcporterだった。でも、mcp-cliもかなり似た感じだね。

記事には重要なコンテキストが欠けてるね。まず、MCP ツールはリクエストごとに送信される。Notion の MCP 検索ツールの説明を見てみると、基本的にミニチュートリアルみたいになってる。これがコンテキストウィンドウに直で入るから、ほとんどの場合、MCP ツールの読み込みは全か無かなんだよね（他の手段でツールを事前選択しない限り）。一般的に MCP はコンテキストをかなり膨らませちゃう。最近 GitHub Copilot の VSCode 拡張で約 20 のツールを数えたけど、これは多いよ！次に、MCP ツールは合成できない。Notion の検索ツールを呼び出すと、彼らが返すことに決めたものが全部返ってくるから、量が多いかもしれない。モデルにはどれだけのデータを処理するか決める手段がないんだ。通常、識別子や URL みたいなトークンに優しくないデータポイントがたくさん含まれた JSON データダンプが返ってくる。一方で、CLI ベースのアプローチはスクリプト可能。コーディングアシスタントは通常、jq や tail を使ってデータをチャンクごとに処理するようにパイプするから、最近はこうやってトレーニングされてるんだよね。エージェントで MCP を使いたいなら、MCP モデルとそのすべてのバッジを持ち込む必要があるけど、これはかなりの量になる。OAuth の処理、ツールの読み込みと選択、リロードなどを扱わなきゃいけない。シンプルな解決策は、すべてのことをシステムレベルで扱う単一の MCP サーバーを持って、そこからツールを呼び出す小さな CLI を持つことだと思う。mcpshim の場合（別のコメントで投稿したやつね）、CLI は非常にシンプルな UNIX ソケットを使ってサーバーと通信して、簡単な JSON でやり取りするんだ。実際、5 行のコードで bash クライアントを作れるくらい簡単。最近の AI エージェントは SKILLs の使い方を知ってるから、この方法はほぼ普遍的だよ。だから、もっと CLI ツールを増やすのが目標なんだ。でも、すべてのサービスのために CLI を書く代わりに、既存の MCP の上にピボットすればいいんだ。これでコンテキストの問題を非常にエレガントに解決できると思う。

└

要するに、MCPを使う最良の方法は、全く使わずにAPIを直接呼び出すかCLIを通じて呼び出すことだね。もしそれがなければ、MCPをCLIにラップするのが次善の策。MCPの意味って何だろうって考えちゃうね。

└

自分でMCPサーバーを書いて、オンデマンドで起動する小さなツールをたくさん作るか、スマートさや第二層のLLMを使ってGQLクエリをその場で作成して結果を減らすのもいいよ。今は書くのが結構簡単だし。MCPのコンテキスト管理はもっと良くなるべきだと思う。Amazonのkiroがそれに挑戦したみたい。

└

あなたの説明からすると、GraphQLやSQLもAIのコンテキストに良い解決策かもしれないね。

└

それに加えて、すべてのツールには --json（そして可能なら --output-schema フラグ）を持たせるべきだと思う。後者は、膨れ上がったトークン非効率なJSONスキーマではなく、TypescriptやPydanticなどの型定義を返すべきだよ。そういう情報は一箇所に集約されるべきだね。これで、エージェントはツールを直接実行するか（出力をコンテキストに持ってくる）、スクリプト経由で実行するか（またはjqにパイプするだけ）を選べるようになる。これにより、正確な算術計算やさらなるコンテキストの圧縮が可能になるんだ。

これ、Awesome CLIs/TUIs や Terminal Trove に関連してるね。CLI と TUI アプリがたくさんあるよ。Awesome TUIs: https://github.com/rothgar/awesome-tuis Awesome CLIs: https://github.com/agarrharr/awesome-cli-apps Terminal Trove: https://terminaltrove.com/ これ、CLI と UNIX が2026年に戻ってくることを示してるんじゃないかな。

└

実は、これと CLIHub を組み合わせて、誰かがすべての公式 MCP や CLI（または MCP から CLI への）を一つのコマンドでダウンロードできるディレクトリを作りたいんだ。

この記事は少し前のものかな？ > 「エージェントが何か有用なことをする前に、どのツールが使えるかを知っておく必要がある。MCP の答えは、すべてのツールカタログを JSON スキーマとして会話にダンプすることだ。すべてのツール、すべてのパラメータ、すべてのオプション。」 これは、Claude Code のような最高のクライアントにはもう当てはまらないんだ。Skills が設計されたのと同じように、MCP ツールも（Claude Code ではそうしてるけど）すべてをコンテキストにダンプすることなく機能できる。詳しくは https://www.anthropic.com/engineering/advanced-tool-use と https://x.com/trq212/status/2011523109871108570 と https://platform.claude.com/docs/en/agents-and-tools/tool-us... [1] https://agentskills.io/specification#progressive-disclosure

└

ちなみに、ブログには Anthropic の Tool Search との直接比較があるよ。とはいえ、ほとんどの MCP はダンプしてる。Cloudflare の MCP は素晴らしいけど、他の 1000 の有用な MCP はそうじゃない。

Cloudflare の Code Mode MCP のブログ記事を読んだ後[1]、CMCP[2] を作ったんだ。これで、すべての MCP サーバーを 2 つの MCP ツール（検索と実行）の背後に集約できる。Anthropic の Tool Search が MCP の膨張を助けるのは理解してるけど、Claude にしか限られてるんだ。CMCP は現在 Codex と Claude をサポートしてるけど、もっとクライアントを追加するための PR は大歓迎だよ。[1] https://blog.cloudflare.com/code-mode-mcp/ [2] https://github.com/assimelha/cmcp

└

CMCPとCLIのトークン使用量の比較、チェックした？

永続的な解決策としては、AIラボが追加の推論コストなしでコンテキストの長さを増やすより良いアテンションメソッドを見つけることだと思う。それに、システムプロンプトをアカウントに追加できる人には、もっと深い割引（例えば-99%）を提供することも。これで、すべてのMCPをシステムプロンプトに組み込んで、AIプロバイダーにプロンプトを保存して、APIコストをオーバーペイせずに使えるようになる。今の「オンデマンドツール」の回避策は、あまり使わないツールにはいいけど、将来的には同じコンテキストウィンドウ内で柔軟に使えるツールがたくさん必要になるエージェントが登場すると思う。だから、コンテキストウィンドウを長くして、この機能を安く使えるようにする必要があるね。

ちょっと違った視点から見てるんだけど、CLIアプローチはトークン削減に実用的なメリットがあるよね。全体のスキーマをランタイムコンテキストに詰め込まないのは明らかに良いこと。でも、私の主な関心は「トークンコスト」よりも「セマンティックスペースの構造」にあるんだ。MCPは基本的にツールレベルのプロトコルだし、既存のパラダイムであるSkillsは、ツールの発見や段階的開示を通じてコンテキストの膨張や選択のオーバーヘッドをかなりうまく軽減してる。だから、これを単に「MCP対CLI」として捉えるのは、根本的なアーキテクチャの変化というよりは、実行面をシフトさせてるだけに感じる。私が探求している方向性は少し違うんだ。ツールを主要な単位として扱うのではなく、その上にあるセマンティックプリミティブ（例えば「検索」「読む」「作成」）を正規化したらどうなる？サービスはそのセマンティクスの投影を提供するだけになる。これで、セマンティックスペース自体を圧縮して、遅延的に公開し、実行時に具体的なツール/CLI/MCPアダプターを引き込むことができる。Skillsでこれを近似することはできるけど、今のメンタルモデルはまだ「ツールの説明」に強く依存してるから、正規化されたセマンティクスをファーストクラスの市民として扱ってないんだ。だから、CLIアプローチは面白い最適化だけど、トークンを節約する以上の本当の構造的なパラダイムシフトかどうかはまだ迷ってる。結局のところ、「どうやってツールを少なく露出させるか」よりも、「エージェントがナビゲートしなきゃいけないセマンティックスペースをどうレイヤー化して圧縮するか」が核心の質問じゃないかな。

└

ポートとアダプター :)

└

もし上の意味的なプリミティブ（例えば「検索」「読む」「作成」）を正規化したらどうなる？使うべき抽象を強制しようとするのは、あまり良い教訓とは言えないね。

└

シェルはすでに君の質問への答えだよ。基本的なシェル構文やよく知られたコマンドは、君が求めている抽象を提供している。cat、grep、パイプやリダイレクトは意味的には純粋じゃないかもしれないけど、ほぼ普遍的で、ツールとしても「意味的プリミティブ」としても広く使われている。最も重要なのは、LLMはすでにそれらを両方の使い方で使えることなんだ。

コンテキストウィンドウのコストが本当の問題だね。MCPのツール説明は、モデルが必要かどうかに関わらず、すべてのリクエストで送信される。もし20個のツールがロードされていたら、モデルが実際のタスクについて考え始める前に、何千トークンものツール説明が消費される可能性がある。CLIツールはこれを完全に回避する。エージェントはツールが存在することと、どんなフラグが必要かを知っていればいいから。実際の出力はパイプで処理され、コンテキストに一括でダンプされるわけじゃない。そして、jqやgrep、headなどにパイプすることで、コンポーザビリティも無料で得られる。だけど、認証の話ではMCPがまだ勝ってるね。ユーザーがSlackやGitHubをウェブUI経由で接続する必要があるなら、どこかでOAuthのやり取りが必要になる。CLIツールは、すでにローカルで資格情報が設定されていることを前提にしているから、開発者向けのツールにはいいけど、消費者向けのAI製品には合わない。特に開発者のワークフローでは、ある人たちがSKILLファイルと呼んでいるものが甘いスポットだと思う。CLIツールがいつ使えるかをエージェントに教えるマークダウン文書だね。小さなコンテキストフットプリント、完全なコンポーザビリティ、エージェントはスキル文書を一度読んでキャッシュできる。

└

私の個人的なコーディングエージェントでは、スキル内にセットアップフェーズを導入したよ。flak.nixとロックファイルでスキルを配布してる。このフレークは必要な依存関係をインストールして設定する。フロントマターのフィールドでは、フレークに渡す必要があるシークレットの名前を定義してる。今のところ、私のスキルフレークを信頼しているからうまくいってる。スキルは私のシステム内で静的だからね。- エージェント用のDockerイメージをビルドして、スキルディレクトリを注入する。- イメージをビルドする際に各スキルを設定する。- セットアップフェーズの前にシークレットをコピーして、直後に削除する。全体的に見て、Nixはスキルにとってかなり良いね :)

私もMCPよりCLIが好きで、その理由について書いたよ。AIとデータを統合するための#FUSEの使い方についてもね：https://www.tabulamag.com/p/a-new-way-to-integrate-data-into 私の最新のCLIはMCPの代わりだよ：https://github.com/StephanSchmidt/human（アルファ版）

MCPの唯一の本当の価値は、サードパーティのSaaSのための認証ハンドシェイクだ。実際のツール実行はサブプロセス呼び出しよりも劣っている。トークンが多くなり、デバッグが難しく、失敗モードも悪化する。もし誰かがOAuthレイヤーをCLIが使える標準に抽出したら、残りのプロトコルが存在する理由はほとんどなくなるだろう。