Skip to main content
Glama
xujfcn

crazyrouter-mcp

by xujfcn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Crazyrouter MCP: chat, image generation and model discovery

Practical guides / 实操入口

Updated 2026-10-12. This MCP server connects supported clients to Crazyrouter using your API key. The repository implements three tools; the gateway's complete catalogue is broader than these tools.

Related MCP server: OpenRouter MCP Server

Tools

Tool

API

Scope

chat

POST /v1/chat/completions

Text messages for models listed for Chat Completions; default gpt-4o-mini

list_models

GET /v1/models plus public endpoint metadata

Live models available to your key; optional category filter

generate_image

POST /v1/images/generations

One synchronous image; default gpt-image-2; model-specific sizes

Model discovery does not imply that this MCP implements each model's protocol. Video, music, transcription, TTS and Midjourney tasks require their own APIs. The old generate_video implementation sent video models to a chat endpoint and has been removed. Use the API documentation for those task APIs.

The server no longer silently replaces failed discovery with a hardcoded model list. Authentication and discovery errors are returned to the client. Categories use public endpoint metadata and name-based audio detection; unknown types appear under other.

Install from npm

Requires Node.js 22 or later.

Configure your MCP client with npx -y crazyrouter-mcp@1.0.1 and set CRAZYROUTER_API_KEY as shown below. The client starts the server automatically.

To build from source instead:

git clone https://github.com/xujfcn/crazyrouter-mcp.git
cd crazyrouter-mcp
npm ci
npm run build

Claude Desktop or Cursor

Create a key in the Crazyrouter console. Add the following to the client's MCP configuration, replacing the key locally:

{
  "mcpServers": {
    "crazyrouter": {
      "command": "npx",
      "args": ["-y", "crazyrouter-mcp@1.0.1"],
      "env": { "CRAZYROUTER_API_KEY": "YOUR_CRAZYROUTER_API_KEY" }
    }
  }
}

Claude Desktop uses its claude_desktop_config.json; Cursor supports .cursor/mcp.json. Restart the client after editing. Do not commit a configuration containing a real key.

VS Code

Use .vscode/mcp.json and the VS Code MCP schema:

{
  "servers": {
    "crazyrouter": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "crazyrouter-mcp@1.0.1"],
      "env": { "CRAZYROUTER_API_KEY": "${input:crazyrouter-api-key}" }
    }
  },
  "inputs": [
    { "type": "promptString", "id": "crazyrouter-api-key", "description": "Crazyrouter API key", "password": true }
  ]
}

Example tool arguments

{"model":"gpt-4o-mini","messages":[{"role":"user","content":"Reply OK"}],"max_tokens":16}

Use only one of max_tokens and max_completion_tokens, according to the model's documented schema. Do not send optional temperature values to models that do not support them.

{"category":"image"}
{"model":"gpt-image-2","prompt":"A simple blue circle on a white background","n":1}

Image output may be a URL or base64 image. The tool returns both formats through MCP and does not report success for an empty result. Size constraints vary by model. Image requests incur the model's normal charges.

Prices and troubleshooting

  • Current models and prices are the source of truth; there is no fixed model count or universal discount.

  • HTTP 400: inspect the exact model ID, endpoint, size and other fields. Start with the minimal example.

  • HTTP 401/403: check your key and permissions. HTTP 429: inspect quota and rate limits.

  • Models requiring a native task API are rejected by the chat/image tools before inference.

  • The fixed API base is https://crazyrouter.com/v1; marketing parameters are never added to API requests.

Development

npm ci
npm run build
npm test

Tests use mocked HTTP responses through an MCP client/server connection. On 2026-10-12, live checks through the updated MCP passed for model discovery, a minimal gpt-4o-mini chat request and one gpt-image-2 image request. This does not establish that every model or media operation has been tested. Maintainers can run node tests/live-smoke.mjs; add --image to include one billable image request.

中文说明

本仓库支持文本聊天、同步图片生成、实时模型发现三个工具。模型目录会返回视频、音乐等类别，但不代表这些能力已在 MCP 中实现。旧版视频工具错误地调用聊天接口，已移除；请按 API 文档使用原生任务接口。

使用 Node.js 22+，按上面的配置通过 npx -y crazyrouter-mcp@1.0.1 启动。也可以克隆仓库后运行 npm ci 和 npm run build，再将本地 dist/index.js 配置到 MCP 客户端。密钥通过 CRAZYROUTER_API_KEY 传入。不要将模型目录中的显示名称当作精确 API ID，也不要将推广参数添加到接口地址。

创建密钥 · 当前模型与价格

License

MIT

Available Tools

4 tools
chatC

Send a message to any AI model via Crazyrouter. Supports 627+ models including GPT-5, Claude Opus 4.6, Gemini 3, DeepSeek R1, Llama 4, Qwen3, Grok 4, and more.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNoThe AI model to use (default: gpt-5-mini). Examples: gpt-5, claude-opus-4-6, gemini-3-pro, deepseek-r1, llama-4-scout, qwen3-235b, grok-4gpt-5-mini
messagesYesArray of chat messages with role and content
temperatureNoSampling temperature (0-2). Lower = more deterministic, higher = more creative
max_tokensNoMaximum number of tokens to generate

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the platform (Crazyrouter) and model support but lacks critical behavioral details: authentication requirements, rate limits, cost implications, response format, error handling, or whether it's stateful/conversational. 'Send a message' implies a write operation but doesn't clarify persistence or side effects.

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?

Two concise sentences with zero waste. The first states the core purpose, the second provides scope/context with specific examples. Well-structured and front-loaded with essential information.

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?

For a tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks crucial context about response format, error conditions, authentication, rate limits, and cost—information an agent needs to use this tool effectively. The model examples are helpful but insufficient for full operational understanding.

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%, providing good documentation for all parameters. The description adds minimal parameter semantics beyond the schema—it mentions model examples but doesn't explain message structure or parameter interactions. Baseline 3 is appropriate since the schema does the heavy lifting.

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 clearly states the action ('Send a message') and target ('to any AI model via Crazyrouter'), with specific examples of supported models. It distinguishes from sibling tools like generate_image and generate_video by focusing on chat interactions rather than media generation. However, it doesn't explicitly contrast with list_models.

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 is provided. The description mentions 'Supports 627+ models' but doesn't explain when to choose specific models or when to use this versus list_models for discovery. Usage context is implied but not stated.

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

generate_imageC

Generate images using AI models via Crazyrouter. Supports DALL-E 3, Midjourney, Flux, Stable Diffusion, and more.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesText description of the image to generate
modelNoImage generation model to use (default: dall-e-3). Options: dall-e-3, midjourney, flux-pro-1.1-ultra, flux-kontext-pro, sd3.5-large, imagen-4.0-generate-001dall-e-3
sizeNoImage size. For DALL-E 3: 1024x1024, 1024x1792, 1792x1024.
nNoNumber of images to generate (1-4, default: 1)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the service provider ('Crazyrouter') and lists supported models, but doesn't describe what happens during generation (e.g., processing time, rate limits, authentication needs, cost implications, or what the output looks like). For a generative AI tool with zero annotation coverage, this leaves 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.

Conciseness4/5

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

The description is a single, efficient sentence that communicates the core purpose and lists key supported models. It's appropriately sized and front-loaded with the main action. However, it could be slightly more structured by separating purpose from model examples for better readability.

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?

For a generative AI tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (image URLs, binary data, metadata), processing behavior, error conditions, or usage constraints. The lack of output schema means the description should ideally cover return values, but it doesn't.

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 all four parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. It mentions model names but doesn't provide guidance on when to use specific models or size options. Baseline 3 is appropriate 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.

Purpose4/5

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

The description clearly states the action ('Generate images') and the resource ('using AI models via Crazyrouter'), and lists specific model examples. It distinguishes from sibling 'generate_video' by specifying images, but doesn't explicitly contrast with 'chat' or 'list_models'. The purpose is clear but could be more specific about what distinguishes it from other tools.

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 provides no guidance on when to use this tool versus alternatives like 'generate_video' or 'chat'. It mentions supported models but doesn't explain when to choose one model over another or any prerequisites. There's no explicit when/when-not usage context or comparison to sibling tools.

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

generate_videoC

Generate videos using AI models via Crazyrouter. Supports Sora 2, Kling V2, Veo 3, Seedance, Pika, and more.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesText description of the video to generate
modelNoVideo generation model to use (default: kling-v2-1). Options: sora-2, kling-v2-1, veo3, doubao-seedance-1-5-pro_720p, pika-1.5, runway-vip-video, MiniMax-Hailuo-2.3kling-v2-1

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 burden of behavioral disclosure. It mentions 'Generate videos using AI models' and lists models, but doesn't describe what the tool actually does behaviorally—e.g., whether it initiates an async process, returns a video file or URL, requires authentication, has rate limits, or involves costs. For a tool with zero annotation coverage, this is a significant gap, warranting a score of 2.

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 and front-loaded, stating the core purpose in the first phrase. The list of models adds specificity without unnecessary elaboration. However, the second sentence could be integrated more smoothly, and there's some redundancy with the schema's model options, slightly reducing efficiency. Overall, it's appropriately sized with minimal waste.

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 complexity of video generation (likely involving async processing, output formats, etc.), no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a video URL, status, or error details), behavioral aspects like latency or costs, or how to handle the generated content. This inadequacy for a tool with such potential complexity results in a score of 2.

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%, with both parameters ('prompt' and 'model') well-described in the schema. The description adds no additional meaning about parameters beyond implying model options in its list. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate or add value beyond the schema.

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 clearly states the tool's purpose: 'Generate videos using AI models via Crazyrouter.' It specifies the action ('Generate videos') and resource ('AI models'), and lists specific models (Sora 2, Kling V2, etc.) to illustrate capability. However, it doesn't explicitly differentiate from sibling tools like 'generate_image' beyond implying video vs. image generation, which is why it's a 4 rather than a 5.

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 provides no guidance on when to use this tool versus alternatives like 'generate_image' or 'chat'. It lists supported models but doesn't indicate when to choose one model over another or any prerequisites for usage. This lack of explicit when/when-not/alternatives guidance results in a score of 2.

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

list_modelsB

List available AI models on Crazyrouter. Filter by category: chat, image, video, audio, or music.

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNoFilter models by category. Options: chat, image, video, audio, music. Omit to show all categories.

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 full burden. It mentions filtering by category but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, or what 'available' means (e.g., free vs. paid, active vs. all). This leaves gaps in understanding how the tool behaves beyond basic listing.

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, efficient sentence that front-loads the purpose ('List available AI models on Crazyrouter') and adds necessary detail ('Filter by category...'). There is zero waste, and every word earns its place, making it highly concise and well-structured.

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 low complexity (one optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameter use, but lacks details on output format, error handling, or behavioral context. Without annotations or output schema, more completeness would be beneficial for an AI agent.

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%, with the parameter 'category' fully documented in the schema (including enum values and omission behavior). The description adds minimal value by listing the categories, which is already in the schema, but doesn't provide additional semantics like examples or edge cases. Baseline 3 is appropriate as the schema does the heavy lifting.

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 clearly states the action ('List available AI models') and resource ('on Crazyrouter'), with specific filtering capability by category. It distinguishes from siblings like 'chat', 'generate_image', and 'generate_video' by being a listing tool rather than a generation tool. However, it doesn't explicitly contrast with potential other listing tools (none present in siblings).

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 for listing models with optional filtering, but doesn't explicitly state when to use this tool versus alternatives. Since siblings are generation tools (chat, generate_image, generate_video), the distinction is clear by function, but no explicit guidance on when to choose listing over generation or vice versa is provided.

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.

  1. 4 tool updatesv1.0.0
    • First observedchat
    • First observedgenerate_image
    • First observedgenerate_video
    • First observedlist_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

A3.5/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: chat handles text generation, generate_image handles image creation, generate_video handles video generation, and list_models handles model discovery. There is no overlap in functionality, making it easy for an agent to select the correct tool for each task.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: chat, generate_image, generate_video, and list_models. The naming is straightforward and predictable, with no deviations in style or convention across the set.

Tool Count5/5

With 4 tools, this server is well-scoped for its purpose of accessing AI models via Crazyrouter. Each tool earns its place by covering key functionalities: text, image, video generation, and model listing, without being overly sparse or bloated.

Completeness4/5

The tool set covers the core AI generation domains (text, image, video) and model discovery, but there are minor gaps such as missing audio or music generation tools mentioned in the list_models description. However, agents can work around this by using chat or other tools for those purposes.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers