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

그런 다음 게이트웨이를 재시작합니다. 이제 에이전트가 MCP 도구를 사용하여 OpenRouter 모델을 쿼리할 수 있습니다.

참고: OPENROUTER_API_KEY는 선택 사항이지만 더 높은 속도 제한(분당 200회 요청 vs 분당 20회 요청)을 위해 권장됩니다. 키 발급: https://openrouter.ai/keys

에이전트 사용 예시:

# 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")

독립 실행형 (stdio)

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

사용 가능한 도구

도구	설명
`list_models`	모달리티 필터 및 정렬 옵션을 사용하여 모든 모델 나열
`get_model`	ID를 통해 특정 모델의 상세 정보 조회
`search_models`	쿼리, 제공자, 가격, 컨텍스트, 기능별로 모델 검색 및 필터링
`compare_models`	여러 모델을 나란히 비교
`refresh_cache`	OpenRouter API에서 모델 캐시 강제 새로고침

예시

컨텍스트 길이별로 정렬된 모델 목록

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

100만 토큰당 $5 미만의 Claude 모델 검색

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

3개 모델 비교

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

모델 상세 정보 조회

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

API 참조

`list_models(modality, sort_by)`

modality (str, 기본값: "text"): 출력 유형별 필터링. 옵션: text, image, audio, embeddings, all
sort_by (str, 기본값: "name"): 정렬 기준: name, created, price, context_length

`get_model(model_id)`

model_id (str, 필수): 모델 슬러그, 예: anthropic/claude-sonnet-4.6

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

query (str): 모델 이름/ID/설명 내 자유 텍스트 검색
provider (str): 제공자별 필터링 (예: anthropic, google, openai)
max_input_price (float): 100만 토큰당 최대 입력 가격 (0 = 제한 없음)
min_context (int): 최소 컨텍스트 윈도우 크기
requires_tools (bool): 도구 호출을 지원하는 모델만 표시
requires_vision (bool): 비전/이미지 입력이 가능한 모델만 표시
free_only (bool): 무료 모델만 표시

`compare_models(model_ids)`

model_ids (str, 필수): 쉼표로 구분된 모델 ID 목록

`refresh_cache()`

OpenRouter API에서 모델 캐시를 강제로 새로고침합니다.

속도 제한

API 키 미사용 시: 분당 20회 요청
API 키 사용 시: 분당 200회 요청
모델 데이터는 5분 동안 캐시됩니다

API 키 발급: https://openrouter.ai/keys

라이선스

MIT

기여

기여를 환영합니다! GitHub에서 이슈를 열거나 PR을 보내주세요.

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