How do I use OpenRouter Zero MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OpenRouter Zero MCP ask Claude 3.7 Sonnet to explain this Python traceback" 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.

OpenRouter Zero MCP

by Gabrielrtads

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

⚡ OpenRouter Zero MCP (`openrouter-zero-mcp`)

Smithery Glama

The fastest, lightest OpenRouter MCP server.
Built with zero third-party dependencies in pure Node.js. Boots in under 30ms, uses ~15MB of RAM, and supports multi-model inference (DeepSeek, Claude, Gemini, Llama), catalog search, and credits monitoring on Claude Desktop, Cursor, Antigravity, and Windsurf.

⚡ Why OpenRouter Zero?

Feature	Typical OpenRouter MCPs	`openrouter-zero-mcp`
Dependencies	100+ npm packages or heavy Python venv	Zero (0) native Node.js only
Startup Latency	1.2s - 3.5s	< 30ms instant boot
Memory Footprint	~120MB+	~15MB
JSON-RPC Spec	Often crashes on notifications	100% Spec-Compliant (Handles notifications correctly)

Related MCP server: Zen MCP Server

🚀 1-Click Install via Smithery

Install automatically into Claude Desktop with Smithery:

npx -y @smithery/cli install @Gabrielrtads/openrouter-zero-mcp --client claude

💻 Manual Setup

1. Claude Desktop

Add this to your claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "openrouter": {
      "command": "npx",
      "args": ["-y", "openrouter-zero-mcp"],
      "env": {
        "OPENROUTER_API_KEY": "sk-or-v1-your-key-here"
      }
    }
  }
}

2. Cursor IDE

Open Cursor Settings (Ctrl+Shift+J or Cmd+Shift+J).
Navigate to Features > MCP Servers > Add New MCP Server.
Fill in:
- Name: openrouter
- Type: command
- Command: npx -y openrouter-zero-mcp
- Environment Variables: OPENROUTER_API_KEY=sk-or-v1-your-key-here

3. Antigravity / Windsurf / Claude Code

In your mcp_config.json:

{
  "mcpServers": {
    "openrouter": {
      "command": "npx",
      "args": ["-y", "openrouter-zero-mcp"],
      "env": {
        "OPENROUTER_API_KEY": "sk-or-v1-your-key-here"
      }
    }
  }
}

🛠️ Available MCP Tools

1. `openrouter_chat_completion`

Executes chat completions on any model in the OpenRouter catalog (DeepSeek V3/R1, Gemini 2.5 Flash, Claude 3.7 Sonnet, Llama 3.3 70B, etc.).

Parameters: model, messages, prompt, temperature, max_tokens, reasoning.

2. `openrouter_get_credits`

Checks real-time credit balance, usage, and key parameters.

3. `openrouter_list_models`

Searches and lists models from the OpenRouter API with pricing per 1M tokens and context window size.

Parameters: search (e.g. 'deepseek', 'gemini', 'free'), limit.

4. `openrouter_manage_keys`

Provisions, lists, or revokes API keys via the OpenRouter Management API.

Parameters: action ('list', 'create', 'delete'), name, limit, hash.

🔒 Security & Privacy

All API calls are made directly to https://openrouter.ai/api/v1 with your personal key.
Zero analytics, zero telemetry, zero middleman proxy.
Secrets are read exclusively from environment variables.

📄 License

MIT License — Created with ❤️ by Gabriel Toledo (@Gabrielrtads).

Available Tools

4 tools

openrouter_chat_completionC

Execute chat inference on any model available on OpenRouter (e.g. google/gemini-2.5-flash, anthropic/claude-3.7-sonnet, deepseek/deepseek-v4-flash-0731:US, meta-llama/llama-3.3-70b-instruct).

Name	Required	Description	Default
`model`	No	OpenRouter model ID (default: 'google/gemini-2.5-flash').	google/gemini-2.5-flash
`prompt`	No	Simple prompt string (fallback if 'messages' is omitted).
`messages`	No	Array of messages [{role: 'user'\|'system'\|'assistant', content: '...'}]
`reasoning`	No	Thinking / reasoning config (e.g. { effort: 'high' } or { enabled: true }).
`max_tokens`	No	Maximum completion tokens limit.
`temperature`	No	Sampling temperature (0.0 to 2.0).

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden, yet it discloses nothing about cost/credit consumption, API-key requirements, rate limits, timeouts, or whether calls are stateless. For a paid external-inference call this is a meaningful omission.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One tight, front-loaded sentence with no filler. It is appropriately sized, though its brevity comes at the cost of the missing guidance noted elsewhere.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A six-parameter tool with nested message objects, no output schema, and no annotations needs more than a single sentence. The description omits the fallback relationship between prompt and messages, the response shape, and the cost/auth context an agent needs before invoking.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description's only added value is example model IDs beyond the single default in the schema; it says nothing about how 'messages' interacts with 'prompt' or how 'reasoning' affects output.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource ('Execute chat inference on any model available on OpenRouter') and the model-ID examples make the scope concrete. It is clearly distinguishable from the sibling tools (list_models, get_credits, manage_keys) by resource, though it never names them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance: nothing tells the agent when to prefer 'messages' over 'prompt', when to use this versus other OpenRouter tools, or that it incurs cost/requires an API key. Usage must be entirely inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

openrouter_get_creditsB

Retrieve account balance, credits usage, and API key limits from OpenRouter.

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full disclosure burden. 'Retrieve' implies a read-only operation, but there is no statement about authentication requirements, rate limits, or whether this returns live or cached balance data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence naming the verb and all three returned data categories, with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description usefully enumerates what is returned (balance, usage, key limits), but it omits the shape of those values and any auth or scope caveats. Adequate for a trivial zero-arg read, but not fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify or compensate for. Schema coverage is 100% regardless.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Retrieve') and enumerates the resources returned: account balance, credits usage, and API key limits. This distinguishes it from the other read-oriented sibling (openrouter_list_models) and from the mutating openrouter_manage_keys, though it never names a sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus openrouter_manage_keys (which likely also touches key data) or when credits info would be relevant. The agent must infer usage entirely from the name and resource list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

openrouter_list_modelsC

List available AI models on OpenRouter with filters for name, slug, context window size, and pricing.

Name	Required	Description	Default
`limit`	No	Maximum number of models to return (default: 30, max: 100).
`search`	No	Search keyword for model name or slug (e.g. 'claude', 'gemini', 'deepseek', 'free').

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It does not disclose pagination behavior, rate limits, authentication needs, or what the response looks like; 'available' is the only hint about scope. For a discovery tool with zero annotation coverage this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no padding — the verb and resource lead. The only flaw is the inaccurate filter tail, not the length or ordering.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should say something about returned fields, sorting, or pagination limits, and it does not. Worse, the claimed filters (context window, pricing) are absent from the schema, so the description is incomplete and partly inaccurate for a two-parameter discovery tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the real parameters (limit, search) are documented in the schema. However, the description advertises filters for 'name, slug, context window size, and pricing' that do not exist as parameters, actively misleading the agent about the tool's inputs rather than adding accurate value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (List) and resource (AI models on OpenRouter), which is clearly distinguishable from siblings like chat_completion and manage_keys. It is clear what the tool does, though the trailing filter list overstates the tool's actual capability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The list-models framing implies the discovery use case before calling chat_completion, but the description never states when to use this versus alternatives or any prerequisite context. Usage is left to inference rather than made explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

openrouter_manage_keysB

Manage OpenRouter API keys (list, create, delete) via the Management API. Requires OPENROUTER_MANAGEMENT_KEY.

Name	Required	Description
`hash`	No	Key hash to delete (required for action: 'delete').
`name`	No	Name for the new key (required for action: 'create').
`limit`	No	Credit limit in USD for the new key (optional for 'create').
`action`	Yes	Action to execute.

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It usefully discloses that OPENROUTER_MANAGEMENT_KEY is required, but says nothing about the destructive/irreversible nature of 'delete', whether 'create' returns a secret that is shown only once, or any rate limits. For a tool that can delete credentials, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, correctly front-loaded with the operation set before the auth precondition. Every clause earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a three-action management tool, but with no output schema the description should say something about what 'list' and 'create' return (e.g., key hashes vs. plaintext secrets). That omission is the main incompleteness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents hash, name, limit, and action with conditional requirements. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource with the three supported operations enumerated in parentheses ('list, create, delete'), so the agent knows exactly what the tool covers. It is easily distinguishable from the siblings (chat completion, credits, models), though it does not explicitly contrast itself with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites beyond the auth note, and no exclusions. The agent must infer from the schema enum which action to pick for a given intent; the description contributes no routing logic.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.0Oct 20, 2026
- First observedopenrouter_chat_completion
- First observedopenrouter_get_credits
- First observedopenrouter_list_models
- First observedopenrouter_manage_keys

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.4/5.0

Scored 2026-10-20 02:30 across 4 tools

Disambiguation5/5

Each tool targets a clearly distinct area: chat inference, account credits, model listing, and API key management. There is no meaningful overlap or ambiguity in intent.

Naming Consistency4/5

All tools share the openrouter_ prefix and snake_case format, which is highly consistent. The only minor deviation is openrouter_chat_completion, which is noun-based rather than verb_noun like the other three.

Tool Count5/5

Four well-scoped tools cleanly cover the OpenRouter integration surface without redundancy. Each tool earns its place for a focused MCP server.

Completeness4/5

Core workflows are covered: inference, model discovery, credits, and key lifecycle. Minor gaps exist around richer generation options (e.g. embeddings, streaming controls, per-model usage), but agents can work around them.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

OpenRouter AOAuth
ai.openrouter.mcp
The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.
AI & Machine Learning
1
https://mcp.openrouter.ai/mcp
treg.toOAuth
io.github.superdesigndev
OpenRouter for tools and data. Compare catalog providers and call them from one hosted MCP endpoint.
Agent Orchestration
1709
https://treg.to/mcp
BrainstormRouter MCP Server
io.github.justinjilg
AI routing, memory, guardrails, and governance. Routes across Claude, GPT, Gemini.
RAG Systems Knowledge & Memory Agent Orchestration
2
https://api.brainstormrouter.com/v1/mcp/connect
Oriora RouterOAuth
com.orioralabs
AI model routing on your own vendor keys: pick the best model per prompt, or route and run it.
AI & Machine Learning Agent Orchestration
2
https://api.orioralabs.com/mcp

Related MCP Servers

OpenRouter MCP Server
Agent Orchestration Autonomous Agents
heltonteixeira
A
license
A
quality
D
maintenance
Provides integration with OpenRouter.ai, allowing access to various AI models through a unified interface.
Updated a year ago (2025-11-08 14:21 UTC)
4
156 npm
64
Apache 2.0
Zen MCP Server
Developer Tools Autonomous Agents Code Execution
MCP-Mirror
F
license
Not graded
quality
Not graded
maintenance
Gives Claude Desktop access to multiple AI models (Gemini, OpenAI, OpenRouter, Ollama) for enhanced development capabilities including extended reasoning, collaborative development, code review, debugging, and large context analysis with conversation threading.
Updated a year ago (2025-06-25 18:00 UTC)
18 npm
1
-
OpenRouter MCP Multimodal
AI & Machine Learning Image & Video Processing
Amama-Fatima
A
license
Not graded
quality
D
maintenance
Enables chat and image analysis through OpenRouter.ai models. Supports text chat, image generation, and analysis with multiple images and custom questions.
Updated 8 months ago (2026-03-04 09:37 UTC)
721 npm
Apache 2.0
Routara MCP Server
AI & Machine Learning Image & Video Processing
36412749-collab
A
license
A
quality
B
maintenance
Enables calling 48+ LLMs, image, and video models through Routara's API from Cursor, Claude Desktop, Windsurf, and other MCP clients. Supports chat completions, image generation, and video generation with a single API key.
Updated 17 days ago (2026-10-14 03:48 UTC)
5
20 npm
1
MIT

⚡ OpenRouter Zero MCP (openrouter-zero-mcp)

⚡ Why OpenRouter Zero?

🚀 1-Click Install via Smithery

💻 Manual Setup

1. Claude Desktop

2. Cursor IDE

3. Antigravity / Windsurf / Claude Code

🛠️ Available MCP Tools

1. openrouter_chat_completion

2. openrouter_get_credits

3. openrouter_list_models

4. openrouter_manage_keys

🔒 Security & Privacy

📄 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

⚡ OpenRouter Zero MCP (`openrouter-zero-mcp`)

1. `openrouter_chat_completion`

2. `openrouter_get_credits`

3. `openrouter_list_models`

4. `openrouter_manage_keys`