Summary: zerouter-mcp is an AI API gateway MCP server that lets you check model pricing, browse available models, chat with any supported model (Claude, GPT, Gemini, Grok, Kimi), and compare answers across models — all with one sk- Zerouter API key.
Check pricing (get_pricing, no key needed): Look up per-model USD prices per 1M input/output tokens on Zerouter alongside official vendor list prices; filter by model name substring (e.g. claude, gpt-6) or provider (anthropic, openai, gemini, grok, kimi).
List models (list_models, no key needed): See available model IDs and which endpoint each uses; filter by substring. Uses /v1/models when a key is set, otherwise the public catalog.
Chat with any model (chat, key required): Send a single prompt or a full messages conversation to any model, with optional system, max_tokens (up to 200k; default 1024 for Claude/Kimi) and temperature (0–2). Routing to /v1/messages, /v1/responses or /v1/chat/completions is automatic, or can be overridden via endpoint.
Compare models (compare_models, key required): Send one prompt to 2–4 models in parallel and get each answer back with token usage, latency and estimated cost.
Note: chat and compare_models write to the network and require ZEROUTER_API_KEY; pricing and model listing are read-only and work without one.
Allows sending prompts or message lists to OpenAI GPT and Codex models through Zerouter's OpenAI-compatible endpoints, with optional system prompts, max_tokens, and temperature, and supports parallel comparison of OpenAI model responses with usage and cost metrics.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@zerouter-mcp Compare claude-sonnet-5-5 and gpt-6-sol on this regex question"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
AI API gateway MCP for Claude, GPT, Gemini, Grok and Kimi via Zerouter.
zerouter-mcp connects Claude Desktop, Cursor, Claude Code and other MCP clients to Zerouter, an OpenAI-compatible AI API gateway. With one API key you can chat with any supported model, compare answers side by side, or look up API pricing per 1M tokens, without leaving your editor.
One API key for Claude, GPT, Gemini, Grok and Kimi. The same sk- key routes to every model. Zerouter exposes Anthropic-compatible and OpenAI-compatible endpoints, so it works with Claude Code, Codex and Cursor—change the base URL and keep your existing clients.
API pricing you can check in chat. Claude Opus 5.5 on Zerouter is $1.16 input / $5.81 output per 1M tokens (Anthropic list price $4 / $20). Live rates for GPT, Gemini, Grok and Kimi are on the Zerouter pricing page.
Compare models before you commit. Send one prompt to 2–4 models in parallel and get each answer with token usage, latency and estimated cost.
Stable routing, real models. The model ID you send is the model that runs and the one you're billed for. Prompts aren't rewritten and models aren't swapped.
Host unused subscription quota. If you have an official AI account with capacity you don't use, the Zerouter provider program routes paid traffic to it and pays you the larger share of each request, currently about 80%, in USDC.
Related MCP server: Adaptive LLM Gateway
Tool | What it's for | Needs a key? |
| Current Zerouter API pricing per 1M input/output tokens, next to each vendor's official list price. Filter by model or provider. | No |
| AI model IDs you can call, and which endpoint each one uses. | No (uses |
| Send a prompt or a message list to any model, with optional | Yes |
| Send the same prompt to 2–4 models in parallel. You get each answer back with token usage, latency and an estimated cost. | Yes |
You don't have to think about API formats. chat sends each request to the right Zerouter endpoint for you:
Claude and Kimi go to POST /v1/messages (Anthropic format)
GPT, Codex and Grok go to POST /v1/responses (OpenAI Responses)
Gemini and the compatible channels (Qwen/Dashscope and others) go to POST /v1/chat/completions
If you need to, you can override this with the endpoint argument.
Sign in at zerouter.ai and open the dashboard.
Create an API key. Keys start with sk- and work for every model.
Put it in the ZEROUTER_API_KEY environment variable, as in the configs below.
See the pricing page for current API pricing and the quickstart for setup details.
You need Node.js 18 or newer with npm 10 or newer (bundled with current Node 18/20/22 releases). npx fetches the server straight from GitHub, builds it once and runs it. The first start takes up to a minute while it installs; later starts use the npx cache.
The package isn't published to npm, so use github:ZerouterAI/zerouter-mcp as shown below (not zerouter-mcp). Prefer not to use npx? See Other ways to install.
Edit claude_desktop_config.json. On macOS it's in ~/Library/Application Support/Claude/ and on Windows in %APPDATA%\Claude\:
{
"mcpServers": {
"zerouter": {
"command": "npx",
"args": ["-y", "github:ZerouterAI/zerouter-mcp"],
"env": {
"ZEROUTER_API_KEY": "sk-xxxx"
}
}
}
}Restart Claude Desktop afterwards.
Add this to ~/.cursor/mcp.json for all projects, or to .cursor/mcp.json in a single project:
{
"mcpServers": {
"zerouter": {
"command": "npx",
"args": ["-y", "github:ZerouterAI/zerouter-mcp"],
"env": {
"ZEROUTER_API_KEY": "sk-xxxx"
}
}
}
}claude mcp add zerouter --env ZEROUTER_API_KEY=sk-xxxx -- npx -y github:ZerouterAI/zerouter-mcpAdd --scope user to make it available in every project.
MCPB bundle (Claude Desktop one-click). Download zerouter-mcp-0.1.0.mcpb from the latest release and open it, or drag it into Claude Desktop under Settings → Extensions. Claude Desktop asks for your API key; no Node.js setup needed.
Clone and build. Works with any MCP client that can run a local command:
git clone https://github.com/ZerouterAI/zerouter-mcp.git
cd zerouter-mcp
npm install # also builds dist/ via the prepare scriptThen point your client at the built file, using the absolute path on your machine:
{
"mcpServers": {
"zerouter": {
"command": "node",
"args": ["/absolute/path/to/zerouter-mcp/dist/index.js"],
"env": {
"ZEROUTER_API_KEY": "sk-xxxx"
}
}
}
}For Claude Code: claude mcp add zerouter --env ZEROUTER_API_KEY=sk-xxxx -- node /absolute/path/to/zerouter-mcp/dist/index.js
docker build -t zerouter-mcp .
docker run -i --rm -e ZEROUTER_API_KEY=sk-xxxx zerouter-mcpVariable | Required | Default | Notes |
| For | none | Your key from zerouter.ai |
| No |
| Change it only if you route through a proxy |
| No |
| Timeout for each request |
If no key is set, get_pricing and list_models still work. chat and compare_models return a clear error that tells you where to get a key.
"What does Claude Opus 5.5 cost on Zerouter compared with the official API pricing?"
"Ask gemini-3.8-flash to summarise this file."
"Compare claude-sonnet-5-5, gpt-6-sol and grok-4.6 on this regex question and tell me which answer is right."
"Which models on Zerouter cost less than $0.50 per million input tokens?"
git clone https://github.com/ZerouterAI/zerouter-mcp.git
cd zerouter-mcp
npm install # runs the build through the prepare script
npm test # spawns the server over stdio and calls every tool (no key needed)
npx @modelcontextprotocol/inspector node dist/index.jsStart here: zerouter.ai — get a key and see how it works
Model list: zerouter.ai/models
API pricing: zerouter.ai/pricing
Docs: zerouter.ai/docs
Provider program: provider.zerouter.ai/docs
MIT. Built by the Zerouter team.
Send a prompt or a message list to any Zerouter model (Claude, GPT, Gemini, Grok, Kimi, ...). The request is routed automatically: Claude/Kimi -> /v1/messages, GPT/Grok/Codex -> /v1/responses, Gemini and other models -> /v1/chat/completions. Requires ZEROUTER_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model ID, e.g. claude-sonnet-5-5, gpt-6-sol, gemini-3.8-flash, grok-4.6, kimi-k3 | |
| prompt | No | User prompt. Appended after `messages` if both are given. | |
| system | No | Optional system prompt | |
| endpoint | No | Override routing. Default auto. | |
| messages | No | Conversation history as {role, content} items | |
| max_tokens | No | Max output tokens (default 1024 for Claude/Kimi) | |
| temperature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false and openWorldHint=true, so the description carries real weight by disclosing the per-model-family routing (Claude/Kimi -> /v1/messages, GPT/Grok/Codex -> /v1/responses, others -> /v1/chat/completions) and the API-key auth requirement. It does not disclose rate limits, error behavior, or what a response contains, keeping it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core action before routing mechanics and the auth prerequisite. The middle routing sentence is dense but every clause conveys useful model-to-endpoint mapping; nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and seven parameters, the definition should describe the shape of what comes back (generated text, token usage, routing/endpoint used) so an agent can plan downstream steps. Routing, auth, and parameters are covered well, but the return value remains unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so the documented parameters already stand on their own. The description still adds meaning by explaining how the 'endpoint' override interacts with automatic routing and which models map to which route, going beyond the bare enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('send a prompt or message list to any Zerouter model') and immediately distinguishes itself from the get_pricing/list_models/compare_models siblings, which are informational rather than generative. The automatic routing detail further narrows what this tool uniquely does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than stated: the description explains routing and the ZEROUTER_API_KEY prerequisite, but never says when to choose this tool or when not to. Since the three siblings are clearly different function categories, the omission is minor, but no explicit alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send the same prompt to 2-4 Zerouter models in parallel and return each answer with token usage, latency and estimated cost. Requires ZEROUTER_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| models | Yes | 2 to 4 model IDs | |
| prompt | Yes | ||
| system | No | ||
| max_tokens | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and openWorldHint=true; the description is consistent with both and adds genuinely new context — parallel fan-out execution, an auth requirement (ZEROUTER_API_KEY), and that each answer carries token usage, latency, and estimated cost. It stops short of stating rate limits or what happens if one model fails mid-fan-out.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the core action and return contents, then the prerequisite. Every clause carries information and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does its job by enumerating the returned fields (answer, token usage, latency, estimated cost) and the auth prerequisite. The only gap is guidance on the two undocumented optional params (`system`, `max_tokens`).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description is expected to compensate. It reinforces the `models` count (2-4) and 'same prompt' semantics, which merely restates the schema's minItems/maxItems, and says nothing about `system` or `max_tokens`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('send'), resource ('the same prompt to 2-4 Zerouter models'), and mechanism ('in parallel'), plus the shape of the output. The fan-out comparison semantics make it inherently distinct from the single-model `chat` sibling and from `list_models`/`get_pricing`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the multi-model comparison framing and the 'Requires ZEROUTER_API_KEY' prerequisite, but nothing states when to prefer this over `chat` or explains the cost/rate implications of fanning out. No explicit alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public per-model prices on Zerouter in USD per 1M tokens (input/output), next to the official list price. No API key needed. Data comes from https://www.zerouter.ai/pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Filter by model ID or name substring, e.g. 'claude' or 'gpt-6' | |
| provider | No | Filter by provider: anthropic, openai, gemini, grok, kimi |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, yet the description adds genuinely useful context: no authentication required, the exact data source URL, and the unit/currency (USD per 1M tokens, input/output). This is more than a restatement of the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with zero filler; the core payload (what data, unit, comparison) is front-loaded, and the source URL is relegated to a trailing clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so adequately by stating units, currency, and the list-price comparison. Missing only details like whether results are paginated or how freshness is determined, which are minor for a small read-only catalog call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with two optional filters ('model' substring, 'provider'), so the schema already carries full parameter meaning. The description adds nothing about filtering syntax or behavior, which is the expected baseline when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the resource precisely: per-model prices in USD per 1M tokens, with input/output and a comparison to the official list price. An agent can distinguish it from list_models or compare_models, though the description never names those siblings explicitly to sharpen the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No statement of when to use this versus list_models or compare_models. 'No API key needed' is a usage fact but not a selection rule, and no prerequisites, exclusions, or trigger conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List model IDs available on Zerouter and the endpoint each one uses. Uses GET /v1/models when ZEROUTER_API_KEY is set, otherwise the public catalog at https://www.zerouter.ai/models.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional substring filter, e.g. 'gemini' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint; the description adds meaningful context beyond that — the backend endpoint used (GET /v1/models) and the fallback to a public catalog when the API key is absent, which is genuinely useful behavior disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: what it returns is front-loaded, followed by the auth-dependent sourcing rule. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple read-only list with one optional param and no output schema; the auth/fallback behavior is the key context an agent needs. Missing only explicit sibling routing guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'filter' param is fully documented as an optional substring filter, so the description doesn't need to elaborate. Baseline 3 applies since schema carries the parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (model IDs available on Zerouter) plus what it returns alongside each ID (the endpoint each one uses). Clearly distinguishable from siblings like get_pricing and compare_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and the auth-dependent behavior described (ZEROUTER_API_KEY set vs public catalog), but it never explicitly says when to choose this over compare_models or get_pricing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0chatcompare_modelsget_pricinglist_modelsScored across 4 tools
The four tools have largely distinct purposes: two are catalog/cost lookups (get_pricing, list_models) and two are inference operations (chat, compare_models). The only mild overlap is between get_pricing and list_models, which both surface model-catalog metadata, but their descriptions clearly separate pricing from model-ID/endpoint listing.
Three tools follow a clean verb_noun pattern (get_pricing, list_models, compare_models), which is predictable and readable. 'chat' breaks the pattern as a bare verb, but the deviation is minor and the intent is unambiguous.
Four tools is well-scoped for a multi-model routing service, and each covers a distinct capability: discover models, check prices, run one prompt, or compare several. Nothing feels redundant or padded.
The surface covers the core lifecycle well: discovery (list_models, get_pricing), single-model inference (chat), and multi-model comparison (compare_models). Minor gaps exist, such as no account/balance or usage-limit check and no streaming or embedding support, but these are workarounds rather than blockers.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
Chat, image, video, and audio models from many vendors behind one remote MCP server and one key.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Connect MCP clients to 2,000+ AI models without managing provider API keys.
