Loading ToolBench
MCP server providing access to OpenRouter's unified API for 500+ AI models
The OpenRouter MCP server demonstrates above-average definition quality with well-structured tool names, comprehensive descriptions, and mostly complete schemas. All 9 tools follow the verb_noun naming pattern (openrouter_list_models, openrouter_search_models, openrouter_chat, etc.). Descriptions are detailed (194-500+ chars) and include dependency hints, prerequisites, and explicit guidance on when to call tools. Input schemas are properly defined with Zod types and converted to JSON Schema. However, there are notable gaps: output schemas are documented only in descriptions, not as formal return types; some parameter descriptions could be more granular; and a few tools lack explicit error handling guidance within their definitions. The chat tool is particularly comprehensive with 15+ parameters clearly described, but parameter interdependencies (e.g., mutually exclusive message/messages) could be more explicit. Error responses are not illustrated in tool definitions. The server demonstrates production-grade awareness of LLM tool usage patterns (e.g., explicit warnings to call discovery tools first, emphasis on model ID lookup before chat calls), which significantly elevates quality beyond baseline community servers.
Chat with any AI model available through OpenRouter. Supports streaming responses, multi-turn conversations via sessions, function/tool calling, multimodal/vision input, and structured outputs. REQUIRED: Before calling this tool, you MUST first call openrouter_search_models or openrouter_list_models to discover current model IDs. Do NOT guess or hardcode model IDs from memory - models are updated frequently and your knowledge of model IDs is likely outdated. Always use the latest models available for the best results. If the user specifies exact model IDs, use those. Otherwise, search for the latest/best model for the task. Simplified usage (convenience params): - role: System prompt (e.g. "You are a helpful assistant") - message: User message string or content parts array (text + images) These replace the need to construct a full messages array for simple requests. Full parameters: - model: The model ID (format: "provider/model-name"). Get valid IDs from openrouter_search_models or openrouter_list_models first. - messages: Array of messages with role (system/user/assistant/tool) and content (string or content parts array for multimodal) - session_id: Optional - continue an existing conversation - stream: Whether to stream the response (default: true) - temperature: Response randomness 0-2 (optional) - max_tokens / max_completion_tokens: Maximum tokens to generate (optional) - tools: OpenAI-compatible function definitions for tool calling (optional) - tool_choice: How to select tools - auto/none/required/specific (optional) - response_format: Output format - text, json_object, or json_schema with enforced schema (optional) - verbosity: Constrain response verbosity - low/medium/high/max (optional) - logprobs / top_logprobs: Return token log probabilities (optional) - logit_bias: Bias specific tokens (optional) - user: End-user identifier (optional) - debug: Debug options like echo_upstream_body (optional) Multimodal/Vision: Message content can be an array of content parts [{type:"text",text:"..."},{type:"image_url",image_url:{url:"..."}}]. Vision validation is automatic - non-vision models will be rejected before spending credits. Returns: content, tool_calls, usage, session_id, logprobs
Generate images using AI models through OpenRouter. REQUIRED: Before calling this tool, you MUST first call openrouter_search_models or openrouter_list_models to discover current image generation model IDs. Do NOT guess or hardcode model IDs from memory - models are updated frequently and your knowledge of model IDs is likely outdated. Always use the latest models available. Parameters: - model (required): The image generation model ID. Get valid IDs from openrouter_search_models first. - prompt (required): Text description of the desired image - aspect_ratio (optional): Image aspect ratio (1:1, 16:9, 9:16, etc.) - image_size (optional): Resolution (1K, 2K, 4K) - some models only Returns generated images with metadata including base64 data URLs, MIME types, and token usage.
Output schemas not formally documented. Tool descriptions document return fields in prose, but no explicit JSON Schema or TypeScript return type definitions are provided in the tool registration. This forces LLMs to parse unstructured prose to understand what fields to extract and chain into downstream tools.
openrouter_get_generation has a minimal description (8 words). The description 'Get detailed stats for a specific generation including tokens, cost, latency, and provider info' is adequate but lacks actionable context: when should an LLM call this vs other tools? What is a 'generation ID'? Where does one come from?
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Get a summary of API costs for the current session or all sessions. Parameters: - session_id (optional): Get costs for a specific session - recent_only (optional): Only show recent entries Returns: - Total cost in credits - Token usage breakdown (prompt, completion, total) - Request count - Cost breakdown by model - Cost breakdown by operation type (chat, image, etc.) Use this to monitor your API spending and optimize model usage.
Get your OpenRouter API key credits and usage information. Returns: - Credit limit and remaining balance (if set) - Total usage (all time) - Usage breakdown: daily, weekly, monthly - Free tier status Use this to monitor your API spending and check your key's credit balance.
Get detailed stats for a specific generation including tokens, cost, latency, and provider info
Get all available providers/endpoints for a model with latency, uptime, pricing, and capability details. Returns for each endpoint/provider: - Context length and max completion tokens - Pricing per token (prompt and completion) - Latency percentiles (p50, p90, p99) over last 30 minutes - Uptime percentage over last 30 minutes - Supported parameters and quantization info Use this to compare providers for a specific model and choose the best one for your needs.
Get the OpenRouter MCP server version information. Returns: - Server package name - Server version number - Node.js runtime version Use this to check the server version for compatibility or issue reporting.
List all available AI models from OpenRouter with optional filtering. IMPORTANT: You MUST call this tool (or openrouter_search_models) BEFORE calling openrouter_chat or openrouter_generate_image to discover current, valid model IDs. Never guess model IDs from memory - always look them up first to ensure you use the latest available models. Filters by provider, keyword, context length, modality, and price. Returns model IDs, names, context lengths, pricing, and capabilities.
Search and compare AI models from OpenRouter with advanced filtering, sorting, and relevance-ranked results. IMPORTANT: You MUST call this tool (or openrouter_list_models) BEFORE calling openrouter_chat or openrouter_generate_image to discover current, valid model IDs. Never guess model IDs from memory - always look them up first to ensure you use the latest available models. Features: - Free-text 'query' parameter for natural search (e.g. "claude opus", "fast cheap") with relevance scoring - Filter by capabilities: tool calling, streaming, temperature, reasoning, JSON output, web search, vision, image generation - Sort by price, context length, provider, or relevance - Limit results (default 20, max 100) - Side-by-side comparison output with model rankings
Parameter interdependencies underdocumented. openrouter_chat accepts both 'role'/'message' (convenience params) and 'messages' (full array), but the mutual exclusivity and fallback behavior are not explicitly stated in parameter descriptions. LLMs may pass all three, causing ambiguity.
No error recovery guidance in tool definitions. Descriptions state WHAT tools do and that they require model IDs, but do not include recovery hints (e.g., 'If model_id is invalid, call openrouter_search_models with a keyword to find valid IDs'). This shifts error recovery burden to the LLM.
Pagination not addressed in list/search tools. openrouter_list_models and openrouter_search_models accept a 'limit' parameter but lack explicit documentation of offset/cursor-based pagination, default limit values, or maximum result caps. If a query returns 1000+ models, the tool response will blow the context window.