Is OpenRouter an MCP Server? What It Actually Exposes
Yes, OpenRouter has an MCP server, and it exposes OpenRouter. Here is what it does, what it does not, and how to give the same agent real tools.
Copy this line to your agent to give it tools it did not have to install.
set up https://monid.ai/SKILL.md and use context.dev /web/search to answer a question from the live web
The short answer is yes, and it probably does not do what you are hoping. OpenRouter publishes an official MCP server, and what it exposes is OpenRouter: its model catalog, its pricing, its docs, your credit balance. It is a management surface, not a tool catalog. Separately, OpenRouter documents how to use somebody else's MCP servers with its API, and in that arrangement you supply, run and pay for the tools yourself. This guide covers both accurately, then shows what fills the remaining gap.
Is OpenRouter an MCP server?
Yes. OpenRouter ships an official MCP server, and it exposes eleven tools, all of which are about OpenRouter itself rather than about the world. An agent connected to it can list and inspect models, read per-provider pricing and performance, pull benchmark scores and usage rankings, search OpenRouter's documentation, check your credit balance, and send a test inference call.
What that is genuinely good for
Model selection, by the agent, at run time. If you are building something that should pick its own model based on current price or current benchmark position, this is the correct tool and there is no substitute for it. search-docs is also quietly useful: an agent that can look up the exact tool-calling format in the provider's own docs makes fewer format mistakes than one working from memory.
Every tool except the inference one is read-only, which makes it safe to hand to an agent without much thought.
What it is not
It is not a way for an agent to reach anything outside OpenRouter. There is no tool in that list that reads a web page, enriches a company, pulls a comment thread, transcribes audio or places a call. That is not an oversight; it is what the product is for. The MCP server makes OpenRouter itself agent-addressable, in the same way a Stripe MCP server makes Stripe agent-addressable.
So the answer to the question depends on which noun you stressed. Is OpenRouter an MCP server: yes. Is OpenRouter the MCP server that gives your agent tools: no, and it does not claim to be.
Does OpenRouter have MCP?
OpenRouter has MCP in two distinct senses, and mixing them up is the source of most confusion on this topic. It publishes an MCP server, which is the one above. And it documents how to consume MCP servers you run yourself, which is a different thing entirely.
Direction one: OpenRouter as the server
An agent connects to OpenRouter over MCP and calls tools about models. OpenRouter is the thing being described. Nothing about your data or your product is reachable this way.
Direction two: OpenRouter as the model behind your tools
Your application holds the tools, and OpenRouter provides the model that decides when to call them. OpenRouter's own guide describes the mechanism plainly: you convert MCP tool definitions into OpenAI-compatible tool definitions, pass those in the request, and when the model returns a tool call your code executes it against your MCP server and feeds the result back. The documentation is candid that this is more work than calling a REST endpoint, because MCP is stateful and somebody has to manage the session.
Why the second direction is where the work actually is
Because the tool definitions have to come from somewhere. The conversion step is a small amount of code. Running the servers is not. Each one is an install, a credential, an update path and, if it fronts a paid vendor, a signup and usually a monthly minimum. The bridge OpenRouter documents is real and it works; it just starts from the assumption that you already have the tools, which is the assumption most teams cannot satisfy.
| Aspect | OpenRouter MCP server | Third-party MCP servers via OpenRouter |
|---|---|---|
| Who is described | OpenRouter | Your systems and vendors |
| Who runs it | OpenRouter | You |
| Who holds credentials | OAuth to your account | You, per vendor |
| What the agent can reach | Models, pricing, docs, balance | Exactly what you installed |
| What is still missing | Everything outside OpenRouter | Any tool you have not signed up for |
The pattern is that both directions leave the same hole: tools you do not already have.
How do you use MCP with OpenRouter?
You run the MCP servers, convert their tool definitions to the OpenAI shape, and pass them to OpenRouter's chat completions call, then execute any tool the model asks for and return the result. That is the documented path and it is straightforward code. The part worth planning is where the tools come from.
The three ways teams fill the tool list
Write them yourself, which is right for anything specific to your product. Install per-vendor MCP servers, which is right when the vendor list is short and known. Or point at a layer that already has a catalog, which is right when the list is long or unknown at build time. Most real systems end up with all three, and the mistake is using the second approach for a list that keeps growing.
The part the docs warn you about
OpenRouter's guide is explicit that this is harder than calling a REST endpoint, and the reason is state. An MCP connection is a session: you open it, you list tools, you keep it alive across turns, and something has to own its lifecycle inside a request path that is otherwise stateless. Multiply that by every server you front and you are running a small connection manager you did not plan to write.
This is worth knowing before you choose the per-vendor route, because it is the cost that scales worst. Converting tool definitions is a fixed amount of code no matter how many servers you have. Keeping sessions healthy across a dozen local processes, each with its own failure mode and restart behaviour, is not, and it is the part that turns up in production rather than in the prototype.
Why the third option changes the code shape
With per-vendor servers, adding a capability is a deploy: somebody installs a server, adds a credential, updates config. With a catalog behind one endpoint, adding a capability is a search the agent runs itself. The tool definitions your bridge converts stop being a fixed list and become a query result, which is the difference between an agent that can attempt an unanticipated task and one that cannot.
What Monid is in this picture
Monid is the OpenRouter for agent tools: one key and one balance let an agent discover and call over a thousand tools across many providers, billed per call, with no separate signup per vendor. It ships as an MCP server, so it slots into exactly the arrangement above, and it routes tool calls only. It is never in the inference path, and there is no relationship with OpenRouter beyond borrowing the shape of their idea to describe ours. In practice the two compose: OpenRouter picks the model, Monid supplies the tools.
How do you wire OpenRouter and a tool layer in one config?
You set two independent things: a base URL and key for the model side, and an MCP server entry for the tool side. They never reference each other, which is the whole point, and it means either half can be swapped without touching the other.
Step 0. Both halves, in one client config
What it does. Points the model path at OpenRouter and the tool path at a catalog, in the same client.
The model side. OpenRouter exposes an OpenAI-compatible endpoint, so for most clients this is a base URL and a key in configuration, not code:
export OPENAI_BASE_URL=https://openrouter.ai/api/v1
export OPENAI_API_KEY=<your-openrouter-key>
The tool side. Monid is streamable HTTP with no install, at https://mcp.monid.ai/v1. The terminal clients are one line each:
claude mcp add --transport http monid https://mcp.monid.ai/v1
codex mcp add monid --url https://mcp.monid.ai/v1
In Claude.ai it is Settings, Connectors, Add custom connector, then Connect and authorise. OpenCode takes a block in opencode.json followed by opencode mcp auth monid. Per-client steps are in the MCP quickstart.
What comes back. An agent whose model is chosen by OpenRouter's routing and whose tools are found by searching a catalog. Neither config block mentions the other, so changing model provider does not touch tools and adding a capability does not touch the model path.
What it costs. Nothing to connect. The tool side bills only when a call runs, and the model side bills tokens the way it already did.
Which model gateway should sit on the other side?
Whichever one you would have picked anyway, and the tool layer does not care. The usual comparison is OpenRouter against LiteLLM, and it is a hosted-versus-self-hosted question rather than a feature one: LiteLLM is the open-source proxy you run, normalising many provider APIs behind one OpenAI-compatible interface, while OpenRouter is the managed marketplace you point at. Portkey's gateway is open source too, which makes starting hosted and moving in-house a real path.
The reason this matters here is substitution. Because the model side is a base URL, swapping OpenRouter for a self-hosted LiteLLM is an environment variable and a test run. The MCP entry above is untouched, and the agent keeps every tool it had. Both halves being independently replaceable is the property worth designing for, whichever vendors you start with.
For agents
Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:
set up https://monid.ai/SKILL.md
It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add --label main --key <your-api-key>
More in the CLI quickstart.
Step 1. Search for a capability, not a vendor
What it does. Finds endpoints by description, so the agent can ask for what it needs rather than naming a company it would have to already know about.
The endpoints. The catalog covers web search and extraction, company and people enrichment, social and platform data, browser automation, generative media and agent telephony. Browse it at monid.ai/tools.
The call.
monid discover -q "search the live web and return the page text"
What comes back. Ranked endpoints, each with provider, description, billing shape and a verified tag where we have tested it.
What it costs. Nothing. Discovery is free, which is what makes it reasonable for an agent to look before it has decided anything.
Step 2. Read the schema and the price before spending
What it does. Returns one endpoint's full input schema, its billing shape and the provider's documentation link.
The endpoints. context.dev/web/search runs a search and can scrape every result to markdown in the same round trip, which is one call where the naive version is eleven.
The call.
monid inspect -p context.dev -e /web/search
What comes back. The body schema: query with Google-style operators, numResults from ten to a hundred, domain allow and block lists, a freshness window, country localisation and the markdown options. Plus the billing shape and the docs URL.
What it costs. Nothing. Verified live on 20 August 2026.
Step 3. Run it, and that is the only billable step
What it does. Executes the endpoint and draws down the shared balance at the price already shown.
The endpoints. context.dev/web/search for search plus page text; exa/search when you want neural retrieval and structured output synthesised across sources.
The call.
monid run -p context.dev -e /web/search \
-i '{"query": "mcp tool calling format site:openrouter.ai", "numResults": 10}' -w 120
What comes back. Ranked results with url, title and relevance, and the markdown body of each page when you ask for it. That last part is the difference between handing the model a list of links and handing it the answer.
What it costs. A fraction of a cent per result, and the charge tracks results rather than calls, so numResults is the dial that moves the bill. The Exa endpoint bills per call instead. Prices at monid.ai/tools.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to search the official docs for a provider and quote the exact tool calling format it specifies.📖 See also Live Web Search Your Agent Can Actually Call
Which endpoint should I use for which job?
| Job | Endpoint | Input | Output | Billing |
|---|---|---|---|---|
| Search plus page text in one hop | context.dev/web/search | query, numResults, domain filters | ranked results with optional markdown | per result |
| Neural search, structured output | exa/search | query, type, category, outputSchema | results with optional contents | per call |
| One URL to prompt-ready markdown | context.dev/web/scrape/markdown | url, extraction options | markdown plus page metadata | per call |
| Domain to company firmographics | pdl/v5/company/enrich | name, website, LinkedIn or ticker | firmographics, funding, headcount, tech stack | per call |
Every row verified with monid inspect on 20 August 2026. The table states the billing shape rather than a figure: per call versus per result is what changes how you write the code, and it does not go stale.
When should you not add a tool layer?
When the thing you actually need is model routing. If your problem is comparing providers, controlling cost per token or building a fallback chain, that is OpenRouter's job and Monid does not compete for it. We are not in the inference path at all, and a post that pretended otherwise would be wasting your time.
When your tool list is short and fixed. If the agent needs your database and one vendor, install two MCP servers and skip the router. A catalog earns its place when the vendor list is unknown when you write the code.
And when the vendor you need has a free tier that covers your usage, take the free tier. Per-call pricing beats a stack of subscriptions, not zero.
Conclusion
OpenRouter is an MCP server, and the tools it exposes are about OpenRouter. That is the accurate answer, and it is not a criticism: making your own platform agent-addressable is a good idea and the model-selection tools are genuinely useful. It just means the question people are really asking, which is whether connecting OpenRouter gives their agent capabilities, has the answer no.
The thing worth carrying away is where the two directions leave you. Both the official server and the documented bridge assume the tools already exist, and for most teams that assumption is the entire problem. The model half of agent infrastructure has been consolidated to the point where a single acquisition covered it. The tool half is still a folder of API keys, and it is the half that decides whether the agent can do the job.
Free next step: run monid discover for something your agent currently refuses to attempt, then monid inspect the top result to read its schema and price. Neither spends anything. Start at monid.ai.
FAQ
OpenRouter vs MCP: are they the same kind of thing?
No, they are on different axes. OpenRouter is a product that routes prompts to language models. MCP is a protocol an agent uses to call tools. You can use both at once and most agent stacks do: the model comes through a gateway, the tools come over MCP. The confusion comes from OpenRouter also publishing an MCP server, which makes OpenRouter itself callable as a tool without making it a tool catalog.
Does OpenRouter have a built-in web search tool?
OpenRouter offers web search as a feature on its own platform, which is different from your agent having a search tool it can call with its own parameters. If you want the agent to control the query, the domain filters, the freshness window and whether it also gets the page text, that is a tool call and it needs a tool. context.dev/web/search covers search plus inline markdown in a single round trip, and exa/search covers neural retrieval with structured output.
How do I add a tool layer to Claude Code or Cursor if I am using OpenRouter for models?
The two are configured separately, which is the useful part. The model gateway is a base URL and a key in your client config. The tool layer is an MCP server entry. Neither knows about the other, so you can change model provider without touching tools and add tools without touching the model path. For Monid the fastest route is to hand your agent https://monid.ai/SKILL.md and the key and let it configure itself.
Is there an open source OpenRouter MCP server?
Community MCP servers wrapping the OpenRouter API exist alongside the official one, and they generally expose a similar surface: model listings, completions, cost data. They have the same boundary as the official server, which is that the tools describe OpenRouter. If what you need is a catalog of third-party capabilities rather than another way to reach models, that is a different kind of product, and the gateway taxonomy guide sorts out which is which.
Last updated August 2026.
