OpenRouter の MCP Server を試してみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

2026 年 6 月 25 日に OpenRouter から MCP Server がリリース されました。OpenRouter は LLM のマルチプロバイダゲートウェイとして知られていますが、今回の MCP Server は OpenAI 互換の API を MCP プロトコルで包み直したというよりも、「コーディングエージェントの開発時アシスタント」という別レイヤーとして位置付けられているところが面白い設計です。

https://openrouter.ai/blog/announcements/openrouter-mcp-server/

ちょうど NVIDIA LLM Router v3 や Sakana Fugu など、ルーティング系の話題を続けて書いてきたので、リリース直後のホットなうちに OpenRouter MCP Server も触っておきたいと思って試してみました。

リリース 2 日目の手触りなので、まだ動かないところや公式ドキュメントに書かれていない挙動も出てきました。13 ある tool の挙動、Auto router 経由で実際にどのモデルが選ばれるか、Hermes Agent から接続できるかなどを、実機の数値を交えて紹介します。

OpenRouter MCP Server とは

OpenRouter MCP Server は、リモートホスト型の HTTP MCP サーバーです。ローカルにインストールする必要がなく、https://mcp.openrouter.ai/mcp という単一のエンドポイントに繋ぐだけで、OpenRouter の live data と chat 機能が MCP の tool として使えるようになります。

公式が想定している利用イメージは「コーディングエージェントから OpenRouter の最新情報を引き出して、用途に合いそうなモデルを選んだり、ちょっとした試し打ちをしたりする」というもので、公式ブログにも次のように書かれていました。

The MCP server is a development assistant for your coding agent... Your app should still call the OpenRouter API directly.

つまり、本番アプリケーションのルーティング層を MCP Server に置き換える設計ではなく、あくまで開発時のアシスタントとして使うことを推しています。LLM Router v3 や CCR が「本番の routing 経路」を担うのに対して、OpenRouter MCP Server は「開発エディタ側の補助層」というレイヤ違いとして読むと位置付けが分かりやすくなります。

OAuth フローを実行すると、OpenRouter MCP: <client 名> のラベルが付いた dedicated key が 7 日有効で発行されます。spend cap がデフォルト $10 で頭打ちになるので、開発エージェントに鍵を持たせる用途で安心しやすい設計です。

13 個の tool を眺める

公式ブログでは 11 ツールの紹介だったのですが、ドキュメントを読み込むと実際は 13 個ありました。chat-send だけが課金対象で、残り 12 個は read-only の無料 tool です。

view-skill は、リリース 2 日目の今のところは中身が空でした。ためしに view-skill name="overview" で叩いてみると次のように返ってきます。

Unknown skill "overview". Available skills:

Available skills: の後ろが空なので、まだスキル登録がない状態のようです。本記事公開時点ではプレースホルダ的に存在している tool だと思って良いでしょう。

ほかは 12 個ともそれぞれ違う情報を返してくれるので、開発エージェントの「OpenRouter について何でも聞ける窓口」として揃っています。

Claude Code から OAuth で繋いでみた

設定はとても簡素で、.mcp.json または ~/.claude/mcp.json に次の 1 ブロックを足すだけです。OAuth のクライアント情報や redirect URI は MCP クライアント側が裏で扱ってくれます。

{
  "mcpServers": {
    "openrouter": {
      "type": "http",
      "url": "https://mcp.openrouter.ai/mcp"
    }
  }
}

Claude Code を再起動すると、初回接続時に OAuth フローが走ります。ブラウザが consent 画面に飛び、OpenRouter MCP: Claude Code のラベルで $10 の spend cap、7 日の有効期限が見える画面が出てきます。Approve すると key が発行され、Claude Code に戻ると /mcp コマンドで openrouter が connected 状態になり、13 個の tool 名が並びます。

接続できたら最初の挨拶代わりに mcp__openrouter__ping を叩くと pong が返ってくるので、tool 一覧と疎通確認はこれで完了です。

Auto router 経由で何が選ばれているのか

OpenRouter には Auto router という、prompt の難易度や性質を見てモデルを自動選択してくれる router があり、MCP 経由でも chat-send に model: "openrouter/auto" と指定すれば使えます。試しに 3 種類の質問を投げてみました。

chat-send のレスポンス末尾には毎回こんな footer が自動で付きます。

hello

(model: openrouter/auto, generation id: gen-1782522452-f9zeD9t0SdmiT5Q5iD3U, input tokens: 221, output tokens: 5)

ここで表示される model: openrouter/auto は routing meta（自分が投げた指定）で、実際にどのモデルに振られたかはレスポンス本体には載っていません。本物の selected model を見るには、ここで得られた generation id を generation-get に渡す必要があります。

3 つの generation id を generation-get に通したら、こんな結果になりました。

予想と違ったのは、軽い "hello" でも GPT-5.5 が選ばれたところと、推論質問では Gemini 3.5 Flash の reasoning モードを ON にして通している点です。「推論なら大きなモデル」「軽い質問なら安いモデル」という思い込みとは違うルートを通っていました。

もうひとつ面白かったのは :floor（最安経路を強制する suffix）の効果です。同じ推論質問を :floor 付きで投げても、router は同じ Gemini 3.5 Flash を選びました。Auto router がすでに「最安に近い妥当解」を返している場合、:floor を付けても選択は変わらないようです。ただし、reasoning tokens の数は 262 → 241 と 21 個減っており、コストも $0.002759 → $0.002570（約 7% 安）に下がっていました。同じモデルでも router 内部で reasoning effort を微調整しているのが見て取れます。

Note: OpenRouter API には Auto router の挙動を細かく制御する cost_quality_tradeoff などのパラメータがありますが、MCP の chat-send にはこれらが expose されていません。MCP 経由での Auto router 制御は、model slug の suffix（:floor / :nitro / :free / :online）と provider.sort の組み合わせに限られます。

generation-get で返ってくる JSON には data.model / data.provider_name / data.provider_responses[].model_permaslug / data.native_tokens_reasoning などが揃っていて、router の判定根拠こそ見えませんが、結果は一通り追跡できます。Langfuse のような外部 observability に頼らなくても、開発エージェントから見える範囲で routing を後追いできるのは便利です。

benchmarks と model-endpoints が面白い

benchmarks は Artificial Analysis と Design Arena の 2 つから third-party のベンチを引いてきてくれます。source 引数を省略すれば両方の結果が混ざって返ってきますし、task_type で coding / intelligence / agentic に絞れます。

coding 系で top 5 を引いたら次のような表になりました。as_of は 2026-06-27T00:00:22.821Z です。

並べてみると、Fable 5 は Claude Opus 4.8 と比べて input/output どちらも 2 倍のコストで coding スコアは +2.2pt に留まります。ベンチ的に「Fable 5 が最高」と聞いてはいたものの、Opus 4.8 が 74.3pt で半額に近いコストなのを見ると、coding のような連続使用の用途では Opus 4.8 の方がトレードオフが良いケースが多そうです。こういう判断材料が editor 側に居ながらにして引けるのが、benchmarks の役どころです。

もう一段踏み込みたいときは model-endpoints です。たとえば Claude Opus 4.8 の提供 provider と pricing / latency / throughput を引いてみると次の表が得られます。

Anthropic 直接が p50 1.27 秒で最速、Bedrock us もそれに近い 1.50 秒です。一方で Bedrock eu-west-1 は uptime 100% を維持しつつも p50 5 秒と最遅で、Vertex global は 3.3 秒。throughput では Bedrock us が 69 tok/s で頭ひとつ抜けています。「リージョン pin で latency を妥協するか、Anthropic 直接で速さを取るか」が live data で見えるのは強い情報源です。

Hermes Agent に HTTP MCP として登録してみた

ここまで Claude Code から OpenRouter MCP を触ってきましたが、もうひとつ気になっていたのが Hermes Agent からの接続でした。Hermes Agent は普段の自分のメインの作業エージェントで、cron でニュース配信を回したり、daemon として常駐させたりしています。

OpenRouter MCP の公式ドキュメントには OAuth PKCE しか書かれていないため、daemon から扱うには OAuth クライアントを実装するか、別の認証手段を探す必要があります。

ためしに通常の OpenRouter API key (OPENROUTER_API_KEY、bearer ヘッダ用) で https://mcp.openrouter.ai/mcp を叩いてみました。

curl -sS -X POST https://mcp.openrouter.ai/mcp \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Accept: application/json, text/event-stream" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

結果は HTTP 200、result.tools[] が返ってきました。公式ドキュメントには bearer 認証は明示されていませんでしたが、通常の OpenRouter API key の Authorization: Bearer でも MCP サーバーに接続できるようでした。

これで daemon 側からの登録ルートが見えます。Hermes 側の ~/.hermes/config.yaml の mcp_servers: セクションに次の 6 行を足しました（既存の aws-knowledge-mcp-server や deepwiki と同じ並び）。

mcp_servers:
  # ... 既存
  openrouter:
    url: https://mcp.openrouter.ai/mcp
    headers:
      Authorization: 'Bearer ${OPENROUTER_API_KEY}'
      Accept: application/json, text/event-stream
    timeout: 180
    connect_timeout: 60

${OPENROUTER_API_KEY} は ~/.hermes/.env から自動展開されます。Hermes を再起動せずに hermes mcp list を打つと、新しい行が増えています。

  MCP Servers:

  Name                      Transport                      Tools  Status
  ────────────────────────  ────────────────────────────── ────── ──────────
  openrouter                https://mcp.openrouter.ai...   all    ✓ enabled

✓ enabled で登録されました。これで Hermes Agent 側のセッションからも mcp_openrouter_credits-get / mcp_openrouter_chat-send などが呼べるようになります。OAuth の 7 日失効を気にせず、ニュース cron や delegation 経路からも使えるのは大きな利点です。（その分セキュリティ的な懸念はありますが。。。）

ルーティング 3 兄弟の中での位置付け

NVIDIA LLM Router v3、CCR（Claude Code Router）、OpenRouter Auto + MCP を並べて整理しておきます。

簡単な構造図にすると、本番の routing 層と開発時 assistant 層の二層構造として読めます。

OpenRouter MCP は本番の routing を置き換える機能ではなく、開発エディタ側に「OpenRouter の事情通」を 1 人住まわせるイメージです。generation-get で routing 結果を一通り追跡できるのは、LLM Router v3 の checkpoint + confidence 列に対する OpenRouter MCP の「事後説明」の答えだと思って読めます。

どんなアプリが OpenRouter を使っているのか

app-rankings で過去 30 日（2026-05-28 から 2026-06-26）の coding カテゴリ top 10 を引いたところ、以下のような並びになりました。

Hermes Agent が 1 位で、2 位の Kilo Code の 3.7 倍、4 位の Claude Code の 7 倍のトラフィックを叩き出していました。

価格・データポリシー・気になるところ

OpenRouter 自体は pay-as-you-go のみでサブスクリプションプランはありません。クレジット購入時に 5.5% のプラットフォーム手数料（最小 $0.80）が乗ります。ZDR（zero data retention）はデフォルト ON で、ログを取りたいときだけ opt-in する形です。EU リージョン pin は Enterprise 契約が必要、というのは普通の OpenRouter API と同じです。

MCP Server 経由でも chat-send だけが課金対象で、残り 12 個の read-only tool は無料です。「benchmarks を 100 回叩く」みたいな使い方は、レート制限の範囲であれば追加コスト 0 でできます。

つまずきそうなところ

リリースされたばかりの機能なので、触っているとあちこちで「あれ」と気になる挙動に出会いました。記事公開時点（2026-06-27）で気付いたところをまとめておきます。

chat-send の制御パラメータには限りがあります。OpenRouter API 本体には cost_quality_tradeoff / session_id などの Auto router 制御パラメータがあるのですが、MCP の chat-send にはこれらが expose されていません。MCP 経由で routing を変えたいときは、model slug の suffix（:floor / :nitro / :free / :online）か provider.sort / provider.only / provider.order の組み合わせで間接的に制御する形になります。

openrouter/fusion の generation-get が 404 を返す現象にも当たりました。Auto と Fusion の両方を試したのですが、openrouter/fusion で生成した generation id を generation-get に投げると Generation gen-... not found で返ってきます。openrouter/auto の generation id は問題なく引けるので、Fusion router 側のデータがまだ index されていない過渡状態のように見えました。

view-skill の中身もまだ空でした。Available skills: の後ろがプレースホルダの状態で、リリース初期の今は使えません。スキルが揃ってきたら、別の使い方が出てくるはずです。

tools/list のレスポンスを覗くと、各 tool の annotation に execution.taskSupport: "forbidden" という見慣れないフィールドが付いていました。MCP server が「task として委譲できない」ことをクライアントに伝える拡張のようで、多くの MCP クライアントはまだこれを参照していないと思いますが、agentic な使い方を考えるなら覚えておきたいフィールドです。

OAuth で発行された専用 key の 7 日有効期限も、運用に乗せる際には気になります。MCP クライアント側がどう再認可を扱うかは実装次第なので、運用に乗せる場合はそこの挙動だけ早めに把握しておきたいところです。今回 Hermes 側は bearer 認証に逃げたので、OAuth 失効そのものは起きない構成になっています。

chat-send の streaming 対応は、公式ドキュメントには明示されていません。試した範囲では streamed: true が generation-get に出てきていたので内部的には streaming が起きていそうですが、MCP クライアント側で逐次表示できるかは別の話で、これも未確認のまま残っています。

まとめ

OpenRouter MCP Server を、リリース 2 日目の手触りで触ってみました。13 個の tool は live data 中心で、benchmarks でモデル選びの裏付けを取り、model-endpoints で provider 別の latency を見て、chat-send でちょっと試し打ちして、generation-get で何が選ばれたかを後追いする、という流れがエディタの中で完結するのが面白いですね。

benchmarks や generation-get で取れる数字は、長く運用するルーターまわりの drift 判定にも使えそうな素材になりそうな予感もしているので改めて検証したいと考えています。リリース直後ということもあって未成熟なところは残っていますが、使いどころがたくさんありそうなので今後の進化が楽しみです。

参考リンク

• Introducing the OpenRouter MCP Server（リリース記事）
• OpenRouter MCP Server Docs
• OpenRouter Auto Router
• OpenRouter Pricing
• OpenRouter Zero Data Retention
• hermes-ciel（GitHub）
• NVIDIA LLM Router で LLM の用途別使い分け環境を構築してみた（基礎編）
• NVIDIA LLM Router を自分のペルソナに合わせて再訓練してみた（訓練編）