de en es ja ko ru zh

OpenRouter MCP Server

Name: OpenRouter MCP Server
Author: lumishoang

by lumishoang

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Servidor MCP de OpenRouter

Servidor MCP (Model Context Protocol) para descubrir y consultar más de 300 modelos de IA disponibles en OpenRouter.

Características

Listar modelos — Explora todos los modelos disponibles con precios, límites de contexto y capacidades
Buscar y filtrar — Encuentra modelos por proveedor, precio, longitud de contexto, características (herramientas, visión, etc.)
Comparar modelos — Comparación lado a lado de múltiples modelos
Obtener detalles — Metadatos completos para cualquier modelo específico
Respuestas en caché — Caché de 5 minutos para reducir las llamadas a la API

Related MCP server: NanoBanana MCP Server

Instalación

pip install openrouter-mcp

Uso

Con OpenClaw

Añádelo a la configuración de servidores MCP en tu openclaw.json:

{
  "mcp": {
    "servers": {
      "openrouter-models": {
        "command": "openrouter-mcp",
        "env": {
          "OPENROUTER_API_KEY": "your-api-key"
        }
      }
    }
  }
}

Luego reinicia la puerta de enlace (gateway). Los agentes ahora pueden usar las herramientas MCP para consultar los modelos de OpenRouter.

Nota: OPENROUTER_API_KEY es opcional, pero se recomienda para obtener límites de tasa más altos (200 peticiones/minuto frente a 20 peticiones/minuto). Obtén tu clave en: https://openrouter.ai/keys

Ejemplo de uso por parte del agente:

# Agent can now call MCP tools like:
list_models(sort_by="context_length")
search_models(query="claude", max_input_price=5.0)
get_model(model_id="anthropic/claude-sonnet-4.6")
compare_models(model_ids="qwen/qwen3.6-plus,anthropic/claude-sonnet-4.6")

Independiente (stdio)

export OPENROUTER_API_KEY=your-key
python -m openrouter_mcp.server

Herramientas disponibles

Herramienta	Descripción
`list_models`	Lista todos los modelos con filtro de modalidad y ordenación opcionales
`get_model`	Obtiene información detallada de un modelo específico por ID
`search_models`	Busca y filtra modelos por consulta, proveedor, precio, contexto, características
`compare_models`	Compara múltiples modelos lado a lado
`refresh_cache`	Fuerza la actualización de la caché de modelos desde la API de OpenRouter

Ejemplos

Listar modelos ordenados por longitud de contexto

{
  "name": "list_models",
  "arguments": {
    "modality": "text",
    "sort_by": "context_length"
  }
}

Buscar modelos de Claude por menos de $5/1M de tokens

{
  "name": "search_models",
  "arguments": {
    "query": "claude",
    "provider": "anthropic",
    "max_input_price": 5.0,
    "requires_tools": true
  }
}

Comparar 3 modelos

{
  "name": "compare_models",
  "arguments": {
    "model_ids": "anthropic/claude-sonnet-4.6,qwen/qwen3.6-plus,openai/gpt-5.4"
  }
}

Obtener detalles del modelo

{
  "name": "get_model",
  "arguments": {
    "model_id": "anthropic/claude-sonnet-4.6"
  }
}

Referencia de la API

`list_models(modality, sort_by)`

modality (str, predeterminado: "text"): Filtrar por tipo de salida. Opciones: text, image, audio, embeddings, all
sort_by (str, predeterminado: "name"): Ordenar por: name, created, price, context_length

`get_model(model_id)`

model_id (str, requerido): Slug del modelo, p. ej. anthropic/claude-sonnet-4.6

`search_models(query, provider, max_input_price, min_context, requires_tools, requires_vision, free_only)`

query (str): Búsqueda de texto libre en el nombre/id/descripción del modelo
provider (str): Filtrar por proveedor (p. ej. anthropic, google, openai)
max_input_price (float): Precio máximo de entrada por 1M de tokens (0 = sin límite)
min_context (int): Tamaño mínimo de la ventana de contexto
requires_tools (bool): Solo modelos que admiten llamadas a herramientas
requires_vision (bool): Solo modelos con entrada de visión/imagen
free_only (bool): Solo modelos gratuitos

`compare_models(model_ids)`

model_ids (str, requerido): Lista de IDs de modelos separados por comas

`refresh_cache()`

Fuerza la actualización de la caché de modelos desde la API de OpenRouter.

Límites de tasa

Sin clave API: 20 peticiones/minuto
Con clave API: 200 peticiones/minuto
Los datos del modelo se almacenan en caché durante 5 minutos

Obtén tu clave API en: https://openrouter.ai/keys

Licencia

MIT

Contribución

¡Las contribuciones son bienvenidas! Por favor, abre un issue o un PR en GitHub.

Available Tools

5 tools

compare_modelsB

Compare multiple models side by side.

Args: model_ids: Comma-separated model IDs

ParametersJSON Schema

Name	Required	Description	Default
`model_ids`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/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 burden. It does not disclose behavioral traits such as whether the operation is read-only, potential side effects, or output format. The minimal description lacks sufficient transparency.

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?

The description is very short with no wasted words. It lacks structure (e.g., sections) but remains efficient. A bit more detail could be added without compromising conciseness.

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?

Given the tool's simplicity (1 param) and presence of output schema, the description is incomplete. It fails to describe what 'side by side' means in the output, whether it shows differences or full models, or how results are presented.

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?

The description explains that model_ids is 'comma-separated model IDs,' adding format context beyond the schema (which only specifies type string). However, with 0% schema description coverage, more detail on parameter constraints would improve clarity.

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

Purpose5/5

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

The description clearly states 'Compare multiple models side by side,' specifying the verb 'compare' and the resource 'multiple models.' It distinguishes itself from sibling tools like get_model (single) and list_models (list) by implying a comparative operation.

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 description does not explicitly state when to use this tool versus alternatives. While the purpose implies it's for comparing multiple models, there is no guidance on exclusions or when-not-to-use.

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

get_modelA

Get detailed info for one model.

Args: model_id: Model slug, e.g. 'anthropic/claude-sonnet-4.6'

ParametersJSON Schema

Name	Required	Description	Default
`model_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It states a simple read operation with no side effects, which is accurate but lacks details on potential errors (e.g., if model_id doesn't exist) or caching behavior. The safety profile is implied but not explicit.

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?

The description is extremely concise – one line plus a parameter note – without wasted words. While it lacks formal structure, it efficiently conveys the essential information for a simple getter tool.

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

Completeness4/5

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

Given the tool has one parameter and an output schema, the description covers the core purpose and parameter explanation. Minor omissions like error handling or existence checks could be included, but overall it is sufficient for a straightforward operation.

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?

Schema description coverage is 0%, but the description adds an example value for model_id ('anthropic/claude-sonnet-4.6') and clarifies it must be a model slug. This significantly improves understanding beyond the schema's bare 'Model Id' title.

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

Purpose5/5

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

The description clearly states the tool retrieves detailed info for one model, using a specific verb ('Get') and resource ('detailed info for one model'). It distinguishes itself from siblings like list_models (multiple models) and compare_models (comparison).

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 explicit guidance on when to use this tool versus alternatives like list_models or search_models. The description only states what it does, leaving the agent to infer context without any directional cues.

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

list_modelsB

List models available on OpenRouter.

Args: modality: Filter by output type. Options: text, image, audio, embeddings, all sort_by: Sort by: name, created, price, context_length

ParametersJSON Schema

Name	Required	Description	Default
`modality`	No		text
`sort_by`	No		name

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the filtering and sorting parameters, implying a read-only listing operation. However, it does not mention rate limits, pagination, result limits, or any side effects. For a simple list tool, basic behavioral traits are partially covered but not comprehensively.

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?

The description is concise, with a clear one-liner purpose followed by parameter details in a readable arg list. No unnecessary words. However, the parameter list could be formatted more clearly (e.g., bullet points) for machine parsing, though it remains human-readable.

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?

Given the tool's simplicity (2 optional params, output schema exists), the description is functionally sufficient but lacks context about when to invoke it relative to siblings. It does not mention that it returns a full list or the default behavior (e.g., all modalities). The output schema likely covers return format, but usage context is minimal.

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?

The schema description coverage is 0%, so the description adds meaning by listing possible values for 'modality' (text, image, audio, embeddings, all) and 'sort_by' (name, created, price, context_length). However, it does not explain what each sort option means (e.g., alphabetical, date, cost, token limit), leaving some ambiguity. The added value compensates for schema gaps but is still minimal.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'List models available on OpenRouter.' This directly distinguishes it from siblings like 'compare_models' (comparison), 'get_model' (specific model), and 'search_models' (search). The verb 'List' plus resource 'models' is specific and unambiguous.

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?

The description does not provide any guidance on when to use this tool versus alternatives (e.g., search_models, compare_models). It only describes the parameters, leaving the agent to infer the use case. Without explicit context, the agent may struggle to choose the appropriate tool.

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

refresh_cacheA

Force refresh the model cache from OpenRouter.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/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 burden. The description mentions 'force refresh' but does not disclose potential side effects (e.g., impact on ongoing requests, rate limits, or whether it is idempotent), leaving significant behavioral gaps.

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?

The description is a single sentence, front-loaded with the key action. Every word contributes to the meaning, with no unnecessary information.

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

Completeness4/5

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

Given the tool has no parameters and an output schema exists, the description is largely complete for its purpose. It explains the action, and the output schema can document return values. However, it lacks any usage context or behavioral notes that could be useful.

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 has zero parameters, so the input schema provides complete coverage. Per guidelines, baseline is 4. The description adds no additional parameter meaning, but that is acceptable given no parameters exist.

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

Purpose5/5

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

The description clearly states the tool refreshes the model cache from OpenRouter. The verb 'refresh' and resource 'model cache' are specific, and it distinguishes from sibling tools that compare, get, list, or search models.

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 description implies usage when cache is stale but does not provide explicit guidance on when to use or when not to use, nor does it mention alternatives among siblings. The context is clear but lacks exclusions or comparisons.

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

search_modelsA

Search and filter OpenRouter models.

Args: query: Free-text search in model name/id/description provider: Filter by provider (anthropic, google, openai, etc.) max_input_price: Max input price per 1M tokens, 0 = no limit min_context: Minimum context window size requires_tools: Only models supporting tool calling requires_vision: Only models with vision/image input free_only: Only free models

ParametersJSON Schema

Name	Required	Description	Default
`query`	No
`provider`	No
`max_input_price`	No
`min_context`	No
`requires_tools`	No
`requires_vision`	No
`free_only`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

With no annotations, the description must carry the full burden, but it only explains parameter semantics. It does not disclose side effects, authentication requirements, rate limits, or how filters combine. The tool's effect on the system is opaque.

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?

The description is front-loaded with the main purpose and then lists parameters in a clear, compact format. Every line provides essential information without redundancy or filler.

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?

Given the 7 parameters and the existence of an output schema, the description covers parameter purposes but omits context on output format, default behavior, and limitations. It is adequate but not thorough.

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 input schema has 0% description coverage, so the description adds crucial meaning for each parameter, e.g., 'Free-text search in model name/id/description'. It compensates well for the schema's lack of descriptions, though individual parameter explanations are brief.

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

Purpose5/5

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

The description clearly states 'Search and filter OpenRouter models,' identifying both the action (search and filter) and the resource. It is distinct from sibling tools like list_models and get_model, which have different purposes.

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 description lists filters but does not provide explicit guidance on when to use this tool versus siblings. No alternatives or exclusion criteria are mentioned, only implied through the list of parameters.

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.

5 tool updatesv1.0.0Apr 21, 2026
- First observedcompare_models
- First observedget_model
- First observedlist_models
- First observedrefresh_cache
- First observedsearch_models

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-05-04 03:00 across 5 tools

Disambiguation5/5

Each tool has a distinct purpose: get single model details, list with basic filters, search with advanced filters, compare multiple, and cache refresh. No overlapping functionality; descriptions clearly differentiate them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using lowercase with underscores: list_models, search_models, get_model, compare_models, refresh_cache. No mixing of conventions.

Tool Count5/5

With 5 tools, the server provides a focused set for model discovery and management. This is neither too few nor too many for the domain of querying model information from OpenRouter.

Completeness5/5

The tool set covers all essential operations for interacting with OpenRouter models: listing, searching, getting details, comparing, and cache management. No obvious gaps like missing model capability queries, as search covers those.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Openrouter A
io.github.pipeworx-io
OpenRouter Models MCP.
AI & Machine Learning Developer Tools
2
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
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
MCP Aggregation Gateway — 22k+ MCP search & call A
cn.pianam.mcp
One AI endpoint to search and call 22k+ MCP servers; 50+ hosted tools work instantly, no key.
Agent Orchestration Search
1

Related MCP Servers

Model Hub MCP
RAG Systems Developer Tools
akiojin
A
license
B
quality
D
maintenance
An MCP server that retrieves and provides AI model information from OpenAI, Anthropic, and Google through a unified interface.
Updated a year ago (2025-07-22 13:34 UTC)
3
10 npm
MIT
NanoBanana MCP Server
caoshuo594
F
license
Not graded
quality
Not graded
maintenance
An MCP server that wraps the OpenRouter API, enabling users to access diverse language models like Google Gemini 3 Pro for chat and image tasks. It provides tools for generating completions and listing available models within MCP-compatible clients.
Updated 10 months ago (2025-12-02 13:08 UTC)
-
OpenRouter MCP Server
AI & Machine Learning Developer Tools
praxeo
A
license
A
quality
D
maintenance
An MCP server that provides access to 400+ AI models via OpenRouter, enabling chat, comparison, and document analysis through Claude.
Updated 3 months ago (2026-06-27 17:48 UTC)
5
43 npm
MIT
OpenRouter Model Selector MCP
AI & Machine Learning Search
rifatsaltoglu
A
license
Not graded
quality
C
maintenance
MCP server that helps AI assistants automatically find, filter, and rank the best AI models for a specific task using the OpenRouter API.
Updated 2 months ago (2026-07-14 11:44 UTC)
1
MIT