Click on "Install 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., "@OpenRouter MCP Bridge Analyze the authentication patterns in the project"
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.
A lightweight MCP (Model Context Protocol) server that enables AI coding assistants to interact with OpenRouter API. Works with Claude Code, Cursor, VS Code, and other MCP-compatible clients.
Direct OpenRouter API Integration: Async HTTP calls using httpx
Simple MCP Tools: Three core functions for queries, file analysis, and batch processing
Stateless Operation: No sessions, caching, or complex state management
Production Ready: Robust error handling with configurable timeouts (default: 90 seconds)
Minimal Dependencies: httpx, python-dotenv, and mcp>=1.0.0
Async/Await: Full async support for concurrent operations
Model Flexibility: Support any OpenRouter-compatible model
Related MCP server: Gemini Bridge
Get OpenRouter API Key:
# Visit https://openrouter.ai/keys
# Sign up and get your API keySet Environment Variable:
export OPENROUTER_API_KEY="your-api-key-here"From PyPI:
pip install openrouter-mcp-bridgeUsing uvx (recommended for MCP servers):
uvx openrouter-mcp-bridgeLocal Development:
# Clone the repository
git clone https://github.com/htooayelwinict/open-bridge.git
cd open-bridge
# Create virtual environment
python3 -m venv .venv
source .venv/bin/activate
# Install in development mode
pip install -e .
# Run directly
python -m srcVariable | Required | Default | Description |
| ✅ Yes | - | Your OpenRouter API key |
| No |
| Model to use |
| No |
| Request timeout (seconds) |
# Add to Claude Code with uvx (recommended)
claude mcp add openrouter-mcp-bridge -s user \
--env OPENROUTER_API_KEY=sk-or-... \
--env OPENROUTER_MODEL=anthropic/claude-3.5-sonnet \
-- uvx openrouter-mcp-bridgeOr add to ~/.claude.json:
{
"mcpServers": {
"openrouter-mcp-bridge": {
"type": "stdio",
"command": "uvx",
"args": ["openrouter-mcp-bridge"],
"env": {
"OPENROUTER_API_KEY": "sk-or-...",
"OPENROUTER_MODEL": "anthropic/claude-3.5-sonnet"
}
}
}
}Tool | Description |
| Direct API query with structured output |
| Pipe file content for analysis |
| Multiple concurrent queries |
# Basic query
consult_openrouter(
query="What authentication patterns are used in this project?",
directory="/path/to/project",
format="json"
)
# File analysis
consult_openrouter_with_stdin(
stdin_content=open("src/auth.py").read(),
prompt="Review this file for security issues",
directory="/path/to/project"
)
# Batch processing
consult_openrouter_batch(
queries=[
{"query": "Analyze authentication patterns"},
{"query": "Review database implementations"}
],
directory="/path/to/project"
)API-First: Direct async HTTP calls to OpenRouter API
Stateless: Each tool call is independent with no session state
Async/Await: Full async support for concurrent operations
Error Handling: Comprehensive HTTP and timeout error handling
MIT License - see LICENSE file for details.
Originally forked from shelakh/codex-bridge.
Focus: A simple, reliable bridge between Claude Code and OpenRouter API.
Consult OpenRouter API in non-interactive mode with structured output.
Processes prompt and returns formatted response. Supports text, JSON, and code extraction formats.
Args: query: The prompt to send to OpenRouter directory: Working directory (required) - for context only format: Output format - "text", "json", or "code" (default: "json") timeout: Optional timeout in seconds (overrides env var, recommended: 60-120)
Returns: Formatted response based on format parameter
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| directory | Yes | ||
| format | No | json | |
| timeout | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states basic behavior (processes prompt, returns formatted response). It does not disclose authentication needs, rate limits, error handling, or whether the operation is destructive.
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?
The description is concise with a brief intro followed by a clear bullet list of parameters. The first two sentences are somewhat redundant ('Processes prompt and returns formatted response' repeats the intro), but overall efficient.
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?
The description covers basic usage and parameters, but lacks context on when to use this vs. siblings, and does not address potential errors or API limitations. An output schema exists but the return description is vague.
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?
The description adds significant meaning beyond the schema, such as explaining 'directory' is for context only, format options ('text', 'json', 'code'), and a recommended timeout range. Schema coverage was 0%.
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?
The description clearly states 'Consult OpenRouter API in non-interactive mode with structured output' and lists supported formats, but does not differentiate from sibling tools 'consult_openrouter_batch' and 'consult_openrouter_with_stdin'.
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 explicit guidance on when to use this tool versus alternatives. The description mentions 'non-interactive mode' but does not specify when not to use it or provide comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consult multiple OpenRouter queries in batch - perfect for CI/CD automation.
Processes multiple prompts concurrently and returns consolidated JSON output. Each query can have individual timeout and format preferences.
Args: queries: List of query dictionaries with keys: 'query' (required), 'timeout' (optional) directory: Working directory (required) format: Output format - currently only "json" supported for batch
Returns: JSON array with all results
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | ||
| directory | Yes | ||
| format | No | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It mentions concurrent execution and individual timeout preferences, but does not address read-only behavior, authentication needs, rate limits, or error handling. The tool is likely read-only (querying), but this is not explicitly stated, leaving some behavioral ambiguity.
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?
The description is reasonably concise at 9 lines with an Args section. It front-loads the purpose and follows with parameter details. Minor redundancy (e.g., 'JSON' mentioned twice) but generally efficient.
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?
Given the tool has 3 parameters (2 required, 1 optional with default), no enums, and an output schema exists (so return details are less critical), the description covers the essential input parameters and behavior. It mentions concurrent processing and consolidated JSON output, which is sufficient for a batch query tool. Missing details like error handling are not critical given the richness of the description.
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 0%, so the description must compensate. It documents that 'queries' is a list of dicts with keys 'query' (required) and 'timeout' (optional), and states that 'format' only supports 'json' for batch. This adds meaningful context beyond the bare schema definition, though 'directory' is only briefly described as 'Working directory'.
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?
The description starts with 'Consult multiple OpenRouter queries in batch' using a specific verb and resource, and clearly distinguishes itself from sibling tools like 'consult_openrouter' (single query) and 'consult_openrouter_with_stdin' (stdin input) by emphasizing the batch aspect and concurrent processing.
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?
The description explicitly recommends the tool for 'CI/CD automation' and explains that it processes multiple prompts concurrently. While it does not explicitly state when not to use it or compare directly to siblings, the context is clear enough to imply batch usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consult OpenRouter with stdin content piped to prompt.
Similar to 'echo "content" | open-bridge "prompt"' - combines stdin with prompt. Perfect for CI/CD workflows where you pipe file contents to the AI.
Args: stdin_content: Content to pipe as stdin (e.g., file contents, diff, logs) prompt: The prompt to process the stdin content directory: Working directory (required) format: Output format - "text", "json", or "code" (default: "json") timeout: Optional timeout in seconds (overrides env var, recommended: 60-120)
Returns: Formatted response based on format parameter
| Name | Required | Description | Default |
|---|---|---|---|
| stdin_content | Yes | ||
| prompt | Yes | ||
| directory | Yes | ||
| format | No | json | |
| timeout | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It explains the input combination and output formatting but does not mention side effects, potential errors, or constraints like rate limits. The basic structure is clear, but deeper behavioral details are absent.
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?
The description is concise, front-loading the core purpose and analogy, followed by a well-structured parameter list. Every sentence contributes meaning without redundancy, making it efficient for an agent to parse.
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?
Given the 5 parameters and no schema descriptions, the description covers all inputs and mentions the output format. However, it omits details about error handling, timeout behavior, and the exact structure of the returned response. The presence of an output schema reduces the need for such details, but slight gaps remain.
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?
The description compensates for the 0% schema coverage by providing clear, actionable explanations for all five parameters, including examples for stdin_content, allowed values for format, and a recommended range for timeout. This adds significant value beyond the schema.
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?
The description clearly states the tool's action: 'Consult OpenRouter with stdin content piped to prompt.' It provides a concrete analogy ('echo ... | open-bridge') and specifies the use case for CI/CD workflows. This differentiates it from sibling tools like consult_openrouter and consult_openrouter_batch, which likely handle standard queries or batched inputs.
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?
The description explicitly identifies the tool as suitable for CI/CD workflows involving piping file contents, but it does not provide guidance on when to avoid this tool in favor of siblings. No exclusions or alternatives are mentioned, limiting decision-making for the agent.
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. Dates show when Glama detected each change.
v1.0.0consult_openrouterconsult_openrouter_batchconsult_openrouter_with_stdinEach tool has a clearly distinct purpose: single query, batch processing, and stdin-piped input. Despite all consulting OpenRouter, the different use cases prevent confusion.
All tools follow a consistent 'consult_openrouter_<modifier>' pattern, making it easy to predict functionality from the name.
Three tools cover the essential interaction modes for the OpenRouter API bridge, neither over nor under-scoped for its purpose.
The set covers the primary consult operation in three modes, which is sufficient for the bridge's core purpose. Minor missing features like model listing are not essential for 'consult' functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/htooayelwinict/open-bridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
