I tried out OpenRouter's MCP Server

Introduction

Hello, I'm Morishige from Classmethod's Manufacturing Business Technology Department.

On June 25, 2026, OpenRouter released its MCP Server. OpenRouter is well known as a multi-provider gateway for LLMs, but what makes this MCP Server's design interesting is that rather than simply wrapping the OpenAI-compatible API in the MCP protocol, it's positioned as a distinct layer: a "development assistant for coding agents."

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

Since I had been writing about routing-related topics in succession — NVIDIA LLM Router v3 and Sakana Fugu — I wanted to try out the OpenRouter MCP Server while it was still hot off the press, so I gave it a go.

Since this is my experience on day 2 after release, I encountered areas that weren't working yet and behaviors not documented officially. I'll introduce the behavior of all 13 tools, which models actually get selected via the Auto router, whether you can connect from Hermes Agent, and more — all with real numbers from hands-on testing.

What Is the OpenRouter MCP Server?

The OpenRouter MCP Server is a remotely hosted HTTP MCP server. There's no need to install anything locally — simply connecting to the single endpoint https://mcp.openrouter.ai/mcp makes OpenRouter's live data and chat functionality available as MCP tools.

The intended use case described by the official team is "pulling the latest OpenRouter information from a coding agent to select a model that fits the purpose and do some quick test calls," and the official blog states:

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

In other words, the design is not meant to replace the routing layer of production applications with the MCP Server — it's promoted purely as a development-time assistant. While LLM Router v3 and CCR handle "production routing paths," reading OpenRouter MCP Server as a "supplementary layer on the development editor side" helps clarify its positioning.

When you run the OAuth flow, a dedicated key labeled OpenRouter MCP: <client name> is issued with a 7-day validity. Since the spend cap defaults to $10, it's a reassuring design for use cases where you hand a key to a development agent.

A Look at the 13 Tools

The official blog introduced 11 tools, but reading through the documentation reveals there are actually 13. Only chat-send incurs charges; the remaining 12 are read-only free tools.

As of day 2 after release, view-skill currently returns empty content. Trying view-skill name="overview" returns the following:

Unknown skill "overview". Available skills:

Since nothing follows Available skills:, it appears no skills have been registered yet. It's safe to think of this as a placeholder tool at the time of this article's publication.

The other 12 tools each return different information, making them a well-rounded "one-stop window for anything about OpenRouter" for development agents.

Connecting from Claude Code via OAuth

The setup is very simple — just add the following single block to .mcp.json or ~/.claude/mcp.json. The OAuth client information and redirect URI are handled behind the scenes by the MCP client.

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

When you restart Claude Code, the OAuth flow runs on first connection. The browser navigates to a consent screen showing a key labeled OpenRouter MCP: Claude Code with a $10 spend cap and 7-day expiry. After approving, the key is issued, and back in Claude Code, the /mcp command shows openrouter in a connected state with all 13 tool names listed.

Once connected, hitting mcp__openrouter__ping as a first greeting returns pong, completing the tool listing and connectivity check.

What Gets Selected via the Auto Router?

OpenRouter has an Auto router that automatically selects a model based on the difficulty and nature of the prompt. You can use it via MCP by specifying model: "openrouter/auto" in chat-send. I tried sending three types of questions.

The response from chat-send always has a footer like this appended automatically:

hello

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

The model: openrouter/auto shown here is the routing meta (the specification I sent), not which model was actually used. To see the actual selected model, you need to pass the generation id obtained here to generation-get.

After running the three generation ids through generation-get, here are the results:

What surprised me was that GPT-5.5 was selected even for the light "hello" question, and that for the reasoning question, the router was routing through Gemini 3.5 Flash with reasoning mode enabled. This ran counter to assumptions like "bigger models for reasoning" and "cheaper models for light questions."

Another interesting finding was the effect of :floor (a suffix that forces the cheapest route). Even when I sent the same reasoning question with :floor, the router selected the same Gemini 3.5 Flash. It appears that when the Auto router is already returning "close to the cheapest reasonable answer," adding :floor doesn't change the selection. However, the number of reasoning tokens decreased from 262 to 241 (21 fewer), and the cost dropped from $0.002759 to $0.002570 (about 7% cheaper). You can observe that even with the same model, the router internally adjusts reasoning effort.

Note: The OpenRouter API has parameters like cost_quality_tradeoff for fine-grained control of Auto router behavior, but these are not exposed in the MCP's chat-send. Auto router control via MCP is limited to combinations of model slug suffixes (:floor / :nitro / :free / :online) and provider.sort.

The JSON returned by generation-get includes fields like data.model / data.provider_name / data.provider_responses[].model_permaslug / data.native_tokens_reasoning, so while the reasoning behind the router's decision isn't visible, the results can be tracked end-to-end. Being able to trace routing retrospectively from within the development agent's view — without relying on external observability tools like Langfuse — is quite convenient.

benchmarks and model-endpoints Are Fascinating

benchmarks pulls third-party benchmark scores from two sources: Artificial Analysis and Design Arena. Omitting the source argument returns results from both mixed together, and you can narrow down by task_type to coding / intelligence / agentic.

Pulling the top 5 for coding returned the following table. The as_of timestamp is 2026-06-27T00:00:22.821Z.

Comparing them, Fable 5 costs twice as much as Claude Opus 4.8 on both input and output, yet the coding score improvement is only +2.2pt. While I'd heard "Fable 5 is the best" benchmark-wise, seeing that Opus 4.8 scores 74.3pt at nearly half the cost suggests that for continuous-use scenarios like coding, Opus 4.8 often offers a better tradeoff. Being able to pull this kind of decision-making material right from the editor is exactly what benchmarks is for.

For deeper analysis, model-endpoints is the next step. For example, pulling the providers and their pricing / latency / throughput for Claude Opus 4.8 gives the following table:

Anthropic direct is the fastest at p50 1.27 seconds, with Bedrock us close behind at 1.50 seconds. Meanwhile, Bedrock eu-west-1 maintains 100% uptime but is the slowest at p50 5 seconds, and Vertex global is at 3.3 seconds. For throughput, Bedrock us leads with 69 tok/s. Having live data to weigh "accept higher latency by pinning to a region vs. prioritize speed with Anthropic direct" is a powerful information source.

Registering with Hermes Agent as an HTTP MCP

So far I've been interacting with OpenRouter MCP from Claude Code, but another thing I was curious about was connecting from Hermes Agent. Hermes Agent is my main working agent — I use it for cron-based news delivery and running it as a daemon.

Since the official OpenRouter MCP documentation only describes OAuth PKCE, using it from a daemon requires either implementing an OAuth client or finding an alternative authentication method.

I tried hitting https://mcp.openrouter.ai/mcp with a regular OpenRouter API key (OPENROUTER_API_KEY, for bearer header use):

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":{}}'

The result was HTTP 200 with result.tools[] returned. While bearer authentication isn't explicitly mentioned in the official documentation, it appears you can connect to the MCP server using a regular OpenRouter API key with Authorization: Bearer.

This reveals a registration path from the daemon side. I added the following 6 lines to the mcp_servers: section of Hermes's ~/.hermes/config.yaml (alongside existing entries like aws-knowledge-mcp-server and deepwiki):

mcp_servers:
  # ... existing
  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} is automatically expanded from ~/.hermes/.env. Running hermes mcp list without restarting Hermes shows a new entry:

  MCP Servers:

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

It registered with ✓ enabled. This means Hermes Agent sessions can now call tools like mcp_openrouter_credits-get and mcp_openrouter_chat-send. Being able to use it from news cron jobs and delegation paths without worrying about the OAuth 7-day expiry is a major advantage. (Though it does come with security considerations...)

Positioning Among the Routing Trio

Let me organize NVIDIA LLM Router v3, CCR (Claude Code Router), and OpenRouter Auto + MCP side by side.

In a simple structural diagram, this can be read as a two-layer structure: a production routing layer and a development-time assistant layer.

OpenRouter MCP is not a replacement for production routing — it's more like having "an OpenRouter insider" living in your development editor. Being able to trace routing results end-to-end with generation-get can be read as OpenRouter MCP's "post-hoc explanation" answer to LLM Router v3's checkpoint + confidence column.

What Apps Are Using OpenRouter?

Pulling the top 10 coding category apps for the past 30 days (2026-05-28 to 2026-06-26) via app-rankings yielded the following:

Hermes Agent ranked #1, generating 3.7 times the traffic of #2 Kilo Code and 7 times that of #4 Claude Code.

Pricing, Data Policy, and Points of Concern

OpenRouter itself is pay-as-you-go only with no subscription plans. A 5.5% platform fee (minimum $0.80) is added at credit purchase time. ZDR (zero data retention) is ON by default, with an opt-in if you want logging. EU region pinning requires an Enterprise contract — same as the regular OpenRouter API.

Even via the MCP Server, only chat-send incurs charges; the remaining 12 read-only tools are free. Use cases like "calling benchmarks 100 times" can be done at zero additional cost within rate limits.

Potential Pain Points

Since this feature just launched, I encountered a number of "hmm, that's odd" behaviors while trying things out. Here's a summary of what I noticed as of the time of publication (2026-06-27).

There are limits to chat-send's control parameters. The OpenRouter API itself has Auto router control parameters like cost_quality_tradeoff / session_id, but these are not exposed in the MCP's chat-send. When you want to change routing via MCP, you need to control it indirectly using model slug suffixes (:floor / :nitro / :free / :online) or combinations of provider.sort / provider.only / provider.order.

I also encountered a situation where generation-get returned 404 for openrouter/fusion. I tried both Auto and Fusion, but passing the generation id from an openrouter/fusion generation to generation-get returned Generation gen-... not found. Since Auto router generation IDs can be retrieved without issue, it looks like Fusion router data isn't indexed yet — a transitional state.

The content of view-skill is also still empty. With Available skills: remaining a placeholder, it's not usable in this early release period. Once skills are populated, new use cases should emerge.

Looking at the tools/list response, each tool's annotation has an unfamiliar field: execution.taskSupport: "forbidden". This appears to be an extension where the MCP server tells clients that it "cannot be delegated as a task." Most MCP clients probably don't reference this yet, but it's a field worth keeping in mind if you're thinking about agentic use cases.

The 7-day expiry on dedicated keys issued via OAuth is also something to keep in mind when putting this into production use. How the MCP client handles re-authorization depends on the implementation, so if you're deploying this operationally, it's worth understanding that behavior early. Since the Hermes side uses bearer authentication, OAuth expiry isn't an issue in that setup.

Streaming support for chat-send is not explicitly mentioned in the official documentation. In my testing, streamed: true appeared in generation-get outputs, suggesting streaming is happening internally, but whether the MCP client side can display responses incrementally is a separate question — and also remains unverified.

Summary

I tried out the OpenRouter MCP Server on day 2 after its release. The 13 tools are centered on live data — it's interesting that the full workflow of using benchmarks to back up model selection, model-endpoints to check provider-by-provider latency, chat-send for quick test calls, and generation-get to trace back what was selected can all be completed within the editor.

I also have a hunch that the numbers obtainable from benchmarks and generation-get could serve as useful material for drift detection in long-running router operations, so I'd like to revisit that with proper verification. There are still rough edges given the recency of the release, but there seem to be plenty of use cases, and I'm looking forward to seeing how it evolves.

Reference Links

• Introducing the OpenRouter MCP Server (release article)
• OpenRouter MCP Server Docs
• OpenRouter Auto Router
• OpenRouter Pricing
• OpenRouter Zero Data Retention
• hermes-ciel (GitHub)
• Building a Use-Case-Specific LLM Environment with NVIDIA LLM Router (Basics)
• Retraining NVIDIA LLM Router to Match My Own Persona (Training Edition)