How do I use OpenRouter MCP Multimodal Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OpenRouter MCP Multimodal Server analyze this screenshot and summarize what it shows" 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.

OpenRouter MCP Multimodal Server

by hoangdn3

Overview Schema Related Servers Score Discussions

TypeScript

Remote

OpenRouter MCP Multimodal Server

Build Status npm version Docker Pulls

An MCP (Model Context Protocol) server that provides chat and image analysis capabilities through OpenRouter.ai's diverse model ecosystem. This server combines text chat functionality with powerful image analysis capabilities.

Features

Text Chat:
- Direct access to all OpenRouter.ai chat models
- Support for simple text and multimodal conversations
- Configurable temperature and other parameters
Image Analysis:
- Analyze single images with custom questions
- Process multiple images simultaneously
- Automatic image resizing and optimization
- Support for various image sources (local files, URLs, data URLs)
Model Selection:
- Search and filter available models
- Validate model IDs
- Get detailed model information
- Support for default model configuration
Performance Optimization:
- Smart model information caching
- Exponential backoff for retries
- Automatic rate limit handling

What's New in 1.5.0

Improved OS Compatibility:
- Enhanced path handling for Windows, macOS, and Linux
- Better support for Windows-style paths with drive letters
- Normalized path processing for consistent behavior across platforms
MCP Configuration Support:
- Cursor MCP integration without requiring environment variables
- Direct configuration via MCP parameters
- Flexible API key and model specification options
Robust Error Handling:
- Improved fallback mechanisms for image processing
- Better error reporting with specific diagnostics
- Multiple backup strategies for file reading
Image Processing Enhancements:
- More reliable base64 encoding for all image types
- Fallback options when Sharp module is unavailable
- Better handling of large images with automatic optimization

Installation

Option 1: Install via npm

npm install -g @stabgan/openrouter-mcp-multimodal

Option 2: Run via Docker

docker run -i -e OPENROUTER_API_KEY=your-api-key-here stabgandocker/openrouter-mcp-multimodal:latest

Quick Start Configuration

Prerequisites

Get your OpenRouter API key from OpenRouter Keys
Choose a default model (optional)

MCP Configuration Options

Add one of the following configurations to your MCP settings file (e.g., cline_mcp_settings.json or claude_desktop_config.json):

Option 1: Using npx (Node.js)

{
  "mcpServers": {
    "openrouter": {
      "command": "npx",
      "args": [
        "-y",
        "@stabgan/openrouter-mcp-multimodal"
      ],
      "env": {
        "OPENROUTER_API_KEY": "your-api-key-here",
        "DEFAULT_MODEL": "qwen/qwen2.5-vl-32b-instruct:free"
      }
    }
  }
}

Option 2: Using uv (Python Package Manager)

{
  "mcpServers": {
    "openrouter": {
      "command": "uv",
      "args": [
        "run",
        "-m",
        "openrouter_mcp_multimodal"
      ],
      "env": {
        "OPENROUTER_API_KEY": "your-api-key-here",
        "DEFAULT_MODEL": "qwen/qwen2.5-vl-32b-instruct:free"
      }
    }
  }
}

Option 3: Using Docker

{
  "mcpServers": {
    "openrouter": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-e", "OPENROUTER_API_KEY=your-api-key-here",
        "-e", "DEFAULT_MODEL=qwen/qwen2.5-vl-32b-instruct:free",
        "stabgandocker/openrouter-mcp-multimodal:latest"
      ]
    }
  }
}

Option 4: Using Smithery (recommended)

{
  "mcpServers": {
    "openrouter": {
      "command": "smithery",
      "args": [
        "run",
        "stabgan/openrouter-mcp-multimodal"
      ],
      "env": {
        "OPENROUTER_API_KEY": "your-api-key-here",
        "DEFAULT_MODEL": "qwen/qwen2.5-vl-32b-instruct:free"
      }
    }
  }
}

Examples

For comprehensive examples of how to use this MCP server, check out the examples directory. We provide:

JavaScript examples for Node.js applications
Python examples with interactive chat capabilities
Code snippets for integrating with various applications

Each example comes with clear documentation and step-by-step instructions.

Dependencies

This project uses the following key dependencies:

@modelcontextprotocol/sdk: ^1.8.0 - Latest MCP SDK for tool implementation
openai: ^4.89.1 - OpenAI-compatible API client for OpenRouter
sharp: ^0.33.5 - Fast image processing library
axios: ^1.8.4 - HTTP client for API requests
node-fetch: ^3.3.2 - Modern fetch implementation

Node.js 18 or later is required. All dependencies are regularly updated to ensure compatibility and security.

Available Tools

mcp_openrouter_chat_completion

Send text or multimodal messages to OpenRouter models:

use_mcp_tool({
  server_name: "openrouter",
  tool_name: "mcp_openrouter_chat_completion",
  arguments: {
    model: "google/gemini-2.5-pro-exp-03-25:free", // Optional if default is set
    messages: [
      {
        role: "system",
        content: "You are a helpful assistant."
      },
      {
        role: "user",
        content: "What is the capital of France?"
      }
    ],
    temperature: 0.7 // Optional, defaults to 1.0
  }
});

For multimodal messages with images:

use_mcp_tool({
  server_name: "openrouter",
  tool_name: "mcp_openrouter_chat_completion",
  arguments: {
    model: "anthropic/claude-3.5-sonnet",
    messages: [
      {
        role: "user",
        content: [
          {
            type: "text",
            text: "What's in this image?"
          },
          {
            type: "image_url",
            image_url: {
              url: "https://example.com/image.jpg"
            }
          }
        ]
      }
    ]
  }
});

Available Tools

7 tools

get_model_infoC

Get detailed information about a specific model

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	The model ID to get information for

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 states the tool retrieves information but doesn't specify whether it's a read-only operation, what permissions are needed, how errors are handled, or what the response format looks like. This leaves significant gaps for an AI agent to understand the tool's behavior.

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 directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, how the data is structured, or potential error conditions. For a tool with no structured behavioral hints, this leaves the AI agent with insufficient context to use it effectively.

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 100%, with the single parameter 'model' documented as 'The model ID to get information for'. The description adds no additional meaning beyond this, such as examples of model IDs or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

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 verb ('Get') and resource ('detailed information about a specific model'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'search_models' or 'validate_model', which likely serve different but related functions.

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. It doesn't mention when this tool is appropriate (e.g., for retrieving metadata) or when to use siblings like 'search_models' (for finding models) or 'validate_model' (for checking compatibility).

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

mcp_openrouter_analyze_audioB

Transcribe audio files and provide raw content. Supports wav/mp3 files from CDN URLs or local paths.

ParametersJSON Schema

Name	Required	Description	Default
`audio_url`	Yes	Path or URL to the audio file (supports CDN URLs, local file paths, wav/mp3 formats)
`model`	No	OpenRouter model to use (e.g., "mistralai/voxtral-small-24b-2507", "openai/gpt-4o-audio-preview")

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 of behavioral disclosure. It mentions that the tool transcribes audio and provides raw content, but it lacks details on behavioral traits such as rate limits, authentication needs, error handling, or whether the operation is read-only or has side effects. This is a significant gap for a tool with no annotation coverage.

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 concise and well-structured in a single sentence, front-loaded with the core purpose ('Transcribe audio files and provide raw content') followed by supporting details. Every part earns its place 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.

Completeness3/5

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

Given the tool's complexity (audio transcription with model selection), lack of annotations, and no output schema, the description is moderately complete. It covers the basic purpose and input sources but misses behavioral context and output details. It's adequate as a minimum viable description but has clear gaps in guiding the agent fully.

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 input schema already documents both parameters (audio_url and model) thoroughly. The description adds minimal value beyond the schema by reiterating supported formats and sources, but it doesn't provide additional semantic context like examples of model choices or usage tips. 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 tool's purpose: 'Transcribe audio files and provide raw content.' It specifies the action (transcribe), resource (audio files), and output (raw content). However, it doesn't explicitly differentiate from sibling tools like mcp_openrouter_chat_completion or mcp_openrouter_analyze_image, which handle different media types, so it misses the top score.

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 by mentioning supported file formats (wav/mp3) and sources (CDN URLs or local paths), but it doesn't provide explicit guidance on when to use this tool versus alternatives. For example, it doesn't compare to sibling tools like mcp_openrouter_chat_completion for text-based tasks or specify prerequisites. This leaves some ambiguity for the agent.

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

mcp_openrouter_analyze_imageC

Analyze an image using OpenRouter vision models

ParametersJSON Schema

Name	Required	Description
`image_path`	Yes	Path to the image file to analyze (can be an absolute file path, URL, or base64 data URL starting with "data:")
`question`	No	Question to ask about the image
`model`	No	OpenRouter model to use (e.g., "anthropic/claude-3.5-sonnet")

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 states what the tool does but doesn't mention authentication requirements, rate limits, cost implications, response format, error conditions, or what types of analysis are possible. For a tool that likely involves API calls and costs, this is a significant gap.

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 states the core purpose without unnecessary words. It's appropriately sized for a tool with clear parameters documented in the schema.

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 no annotations and no output schema, the description should provide more context about what the analysis returns, typical use cases, limitations, or prerequisites. As a vision analysis tool likely making external API calls, the current description is insufficient for an agent to understand the full behavioral context.

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 three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. This meets the baseline expectation when schema coverage is high.

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 ('Analyze') and resource ('an image'), specifying the service provider ('using OpenRouter vision models'). It distinguishes from some siblings like audio analysis or chat completion, but doesn't explicitly differentiate from 'mcp_openrouter_multi_image_analysis' which handles multiple images.

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 guidance is provided about when to use this tool versus alternatives. The description doesn't mention when to choose single-image analysis over multi-image analysis, or when vision analysis is appropriate versus other sibling tools like chat completion or audio analysis.

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

mcp_openrouter_chat_completionC

Send a message to OpenRouter.ai and get a response

ParametersJSON Schema

Name	Required	Description
`model`	No	The model to use (e.g., "google/gemini-2.5-pro-exp-03-25:free", "undi95/toppy-m-7b:free"). If not provided, uses the default model if set.
`messages`	Yes	An array of conversation messages with roles and content
`temperature`	No	Sampling temperature (0-2)

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 but offers minimal information. It mentions sending and receiving messages but doesn't cover rate limits, authentication requirements, costs, response formats, error handling, or any constraints beyond what's implied by the name. For a tool that likely involves API calls with potential costs and limits, this is insufficient.

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 communicates the core functionality without unnecessary words. It's appropriately sized for the tool's complexity and gets straight to the point with zero wasted verbiage.

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 chat completion tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the response looks like, potential costs, rate limits, or how it differs from sibling tools. Given the complexity of the input schema (supporting multimodal messages) and the absence of structured behavioral hints, more context is needed for effective use.

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?

With 100% schema description coverage, the baseline is 3. The description adds no parameter-specific information beyond what's already documented in the comprehensive schema, which details model selection, message structure with roles and multimodal content, and temperature range. No additional parameter context is provided.

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 ('OpenRouter.ai') with the outcome ('get a response'), making the purpose immediately understandable. However, it doesn't distinguish this chat completion tool from its sibling tools like audio/image analysis tools, which would require more specific differentiation.

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. With sibling tools like 'get_model_info', 'search_models', and various analysis tools available, there's no indication of when chat completion is appropriate versus when to use other OpenRouter capabilities.

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

mcp_openrouter_multi_image_analysisC

Analyze multiple images at once with a single prompt and receive detailed responses

ParametersJSON Schema

Name	Required	Description
`images`	Yes	Array of image objects to analyze
`prompt`	Yes	Prompt for analyzing the images
`markdown_response`	No	Whether to format the response in Markdown (default: true)
`model`	No	OpenRouter model to use. If not specified, the system will use a free model with vision capabilities or the default model.

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 receiving 'detailed responses' but doesn't specify format, length, or structure of outputs. It also omits critical details like rate limits, authentication requirements, error handling, or whether the operation is idempotent. For a tool with no annotations and no output schema, this leaves significant gaps in understanding its behavior.

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 core functionality ('Analyze multiple images at once with a single prompt') and adds value ('receive detailed responses'). There is no wasted text, repetition, or unnecessary elaboration, 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.

Completeness2/5

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

Given the complexity of analyzing multiple images with AI, the lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'detailed responses' entail, potential limitations (e.g., image count, size), or how errors are handled. For a tool with 4 parameters and no structured output documentation, more context is needed to ensure reliable use.

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 input schema fully documents all parameters. The description adds no additional meaning beyond what's in the schema, such as examples of valid prompts or image types. However, it does imply the tool handles multiple images, which aligns with the 'images' array parameter. Given high schema coverage, a baseline score of 3 is appropriate.

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: 'Analyze multiple images at once with a single prompt and receive detailed responses.' It specifies the verb ('analyze'), resource ('multiple images'), and scope ('at once'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'mcp_openrouter_analyze_image' (single vs. multiple image analysis), which prevents a perfect score.

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. It doesn't mention sibling tools like 'mcp_openrouter_analyze_image' for single-image analysis or 'mcp_openrouter_chat_completion' for non-image tasks, nor does it specify prerequisites, constraints, or exclusions. Usage is implied by the name and description but not explicitly stated.

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

search_modelsC

Search and filter OpenRouter.ai models based on various criteria

ParametersJSON Schema

Name	Required	Description
`query`	No	Optional search query to filter by name, description, or provider
`provider`	No	Filter by specific provider (e.g., "anthropic", "openai", "cohere")
`minContextLength`	No	Minimum context length in tokens
`maxContextLength`	No	Maximum context length in tokens
`maxPromptPrice`	No	Maximum price per 1K tokens for prompts
`maxCompletionPrice`	No	Maximum price per 1K tokens for completions
`capabilities`	No	Filter by model capabilities
`limit`	No	Maximum number of results to return (default: 10)

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 the full burden of behavioral disclosure. It mentions searching and filtering but doesn't cover key aspects like whether this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like (e.g., list of models with details). This leaves significant gaps for a tool with 8 parameters.

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 directly states the tool's function without unnecessary words. It's appropriately sized for a search tool, though it could be slightly more structured by front-loading key details like the resource type more prominently.

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 (8 parameters, nested objects) and lack of annotations or output schema, the description is insufficient. It doesn't explain behavioral traits, return values, or usage context, making it incomplete for effective agent operation despite the clear purpose.

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 100%, so the input schema fully documents all parameters. The description adds no additional parameter semantics beyond what's in the schema, such as explaining relationships between parameters or usage examples. This meets the baseline for high schema coverage.

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 ('search and filter') and resource ('OpenRouter.ai models'), making the purpose evident. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_model_info' or 'validate_model', which likely serve different purposes but aren't contrasted here.

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 'get_model_info' or 'validate_model'. It mentions filtering criteria but doesn't specify scenarios or prerequisites for selecting this tool over others, leaving the agent without contextual usage direction.

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

validate_modelC

Check if a model ID is valid

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	The model ID to validate

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 the full burden but only states the action without behavioral details. It doesn't disclose traits like whether it's read-only, if it requires authentication, rate limits, or what happens on invalid input (e.g., error handling). This is a significant gap for a tool with zero annotation coverage.

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: 'Check if a model ID is valid'. It's front-loaded with the core purpose, has zero waste, and is appropriately sized for this simple tool.

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 low complexity (1 parameter, no output schema, no annotations), the description is incomplete. It lacks context on behavioral traits, usage guidelines, and output expectations (e.g., boolean result or error details), making it inadequate for effective agent use despite the simple schema.

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 100%, with the parameter 'model' documented as 'The model ID to validate'. The description adds no additional meaning beyond this, such as format examples or validation criteria. 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 tool's purpose: 'Check if a model ID is valid' specifies the verb ('check') and resource ('model ID'), making it understandable. However, it doesn't distinguish from sibling tools like 'get_model_info' or 'search_models', which might also involve model IDs but serve 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 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. It doesn't mention scenarios like verifying model existence before operations or contrast with siblings like 'get_model_info' for detailed info or 'search_models' for discovery, leaving usage context unclear.

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. Dates show when Glama detected each change.

1 tool updatev1.0.0Jan 3, 2026
- Addedmcp_openrouter_analyze_audio
6 tool updatesNov 8, 2025
- First observedget_model_info
- First observedmcp_openrouter_analyze_image
- First observedmcp_openrouter_chat_completion
- First observedmcp_openrouter_multi_image_analysis
- First observedsearch_models
- First observedvalidate_model

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation4/5

Most tools have distinct purposes targeting different resources or actions, such as analyzing audio vs. images vs. chat completions. However, 'mcp_openrouter_analyze_image' and 'mcp_openrouter_multi_image_analysis' could cause some confusion as both handle image analysis, though the multi-image variant is specialized for batch processing.

Naming Consistency3/5

The naming is mixed: some tools use a consistent 'mcp_openrouter_' prefix for multimodal functions (e.g., 'mcp_openrouter_analyze_audio'), while others like 'get_model_info' and 'search_models' follow a simpler verb_noun pattern without the prefix. This inconsistency reduces predictability but remains readable.

Tool Count5/5

With 7 tools, the count is well-scoped for a multimodal server focused on model interactions and analysis. It covers key areas like model management, chat, and various media analyses without being overwhelming or too sparse.

Completeness4/5

The toolset provides solid coverage for OpenRouter's multimodal capabilities, including model search/info, chat, and audio/image analysis. A minor gap is the lack of tools for video analysis or other media types, but core workflows are well-supported.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

treg.toOAuth
io.github.superdesigndev
OpenRouter for tools and data. Compare catalog providers and call them from one hosted MCP endpoint.
Agent Orchestration
1709
OpenRouter AFeaturedOAuth
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
221
Oriora RouterOAuth
com.orioralabs
AI model routing on your own vendor keys: pick the best model per prompt, or route and run it.
AI & Machine Learning Agent Orchestration
2
ToolRouter B
io.github.Humanleap
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
Agent Orchestration Autonomous Agents
471

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hoangdn3/mcp-ocr-fallback'

If you have feedback or need assistance with the MCP directory API, please join our Discord server