Skip to main content
Glama
deenesjakoruzh
stabgan

OpenRouter MCP Multimodal Server

by stabgan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

What is this?

OpenRouter MCP Multimodal is a production-grade Model Context Protocol (MCP) server — listed on the official MCP Registry as io.github.stabgan/openrouter-multimodal. It connects AI coding agents (Cursor, Claude Desktop, VS Code, Windsurf, Cline, and others) to OpenRouter's unified LLM API over stdio.

Unlike text-only MCP servers, one install covers the full multimodal surface:

Capability

Tools

Highlights

Chat

chat_completion, start_chat_completion, get_chat_completion_status

300+ models, :nitro / :floor / :free / :online / :exacto suffixes, provider routing, web search, response caching, reasoning tokens, async jobs for long-running models

Vision

analyze_image, generate_image, generate_image_dedicated

OCR, captioning, VQA, image generation with reference inputs, dedicated Image API with resolution/quality/format control

Audio

analyze_audio, generate_audio, text_to_speech, speech_to_text

Transcription, speech/music generation, dedicated TTS (free Deepgram default; model-specific voices, mp3/pcm), dedicated STT (Whisper/GPT-4o Transcribe)

Video

analyze_video, generate_video, generate_video_from_image, get_video_status

Clip understanding, Veo 3.1 / Seedance 2.0 / Wan 2.7 generation with progress notifications

Catalog

search_models, get_model_info, validate_model, rerank_documents, health_check

Model discovery, validation, reranking, ops health

Production hardening: input/output path sandboxes (including analyze_* local files as of v4.5.2), SSRF guards, structured errors with _meta.code, MCP 2025-06-18 structured outputs, tool icons (2025-11-25), async video progress notifications, and 1000+ automated tests (unit, mock, regression, and live integration).

Related MCP server: OpenRouter MCP Multimodal Server

Quick start

1. Get an API key (free tier works) → openrouter.ai/keys

2. Run the server

export OPENROUTER_API_KEY=sk-or-v1-...
npx -y @stabgan/openrouter-mcp-multimodal

3. Add to your MCP client — copy one JSON block from Install into your client config:

Client

Config location

Cursor

Project: .cursor/mcp.json · User: Cursor Settings → MCP

Claude Desktop

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json · Windows: %APPDATA%\Claude\claude_desktop_config.json

VS Code

.vscode/mcp.json (workspace) or User Settings → MCP

Windsurf

Windsurf Settings → MCP (same mcpServers JSON shape as Cursor)

Use the mcpServers object from Manual config below.

No credits required to start. Free models such as google/gemma-4-26b-a4b-it:free work for chat and vision. Video/audio generation typically needs credits.

Install

MCP servers are distributed through several packaging models. This server is implemented in Node.js/TypeScript; the table below maps each ecosystem method to how you run it here.

Method

Runtime

Best for

This server

npx

Node.js 22+

Most MCP clients (default)

✅ @stabgan/openrouter-mcp-multimodal

uvx / pipx

Python 3.10+ and Node.js 22+

Python-first workflows, same pattern as PyPI MCP servers

✅ mcp-server-openrouter-multimodal

npm global

Node.js 22+

Pin a version without re-downloading

✅

node (local)

Node.js 22+

Contributors / air-gapped builds

✅

Docker Hub

Docker

Isolation, no Node on host

✅ stabgan/openrouter-mcp-multimodal

GHCR

Docker

GitHub-native OCI pulls

✅ ghcr.io/stabgan/openrouter-mcp-multimodal

Smithery CLI

Node.js (via installer)

Interactive install into Claude/Cursor/etc.

✅

MCP Registry

npm or OCI

Official discovery (io.github.stabgan/openrouter-multimodal)

✅ listing

One-click deeplinks

Node.js

Cursor, VS Code, Kiro

✅

Claude Code CLI

Node.js

Terminal-first Claude Code users

✅

MCP Inspector

Node.js

Debug / list tools locally

✅

Windows cmd /c npx

Node.js

Claude Desktop / Cursor when npx not on GUI PATH

✅ see below

pip / uv (direct)

—

Native Python MCP servers only

— use uvx row above

DXT desktop extensions

—

Bundled Claude Desktop .dxt

not yet

Remote HTTP / SSE

—

Hosted Smithery / Cloudflare endpoints

via Smithery

uvx vs npx: In the MCP ecosystem, npx runs npm (Node) packages and uvx runs PyPI (Python) packages. Because this server is Node-based, uvx uses a thin Python launcher that execs npx -y @stabgan/openrouter-mcp-multimodal — you still need Node installed.

One-click

Paste your OPENROUTER_API_KEY when prompted — deeplinks use placeholders so secrets never appear in URLs.

Manual config

export OPENROUTER_API_KEY=sk-or-v1-...
npx -y @stabgan/openrouter-mcp-multimodal
{
  "mcpServers": {
    "openrouter": {
      "command": "npx",
      "args": ["-y", "@stabgan/openrouter-mcp-multimodal"],
      "env": {
        "OPENROUTER_API_KEY": "sk-or-v1-..."
      }
    }
  }
}

Pin a release: "args": ["-y", "@stabgan/openrouter-mcp-multimodal@5.0.1"]

Install uv (includes uvx), ensure Node.js 22+ is also on your PATH, then:

export OPENROUTER_API_KEY=sk-or-v1-...
uvx mcp-server-openrouter-multimodal
# pin npm version: OPENROUTER_MCP_NPM_VERSION=5.0.1 uvx mcp-server-openrouter-multimodal
{
  "mcpServers": {
    "openrouter": {
      "command": "uvx",
      "args": ["mcp-server-openrouter-multimodal"],
      "env": {
        "OPENROUTER_API_KEY": "sk-or-v1-..."
      }
    }
  }
}

pipx equivalent: pipx run mcp-server-openrouter-multimodal

Optional: OPENROUTER_MCP_NPM_VERSION=5.0.1 pins the underlying npm package.

npm install -g @stabgan/openrouter-mcp-multimodal
{
  "mcpServers": {
    "openrouter": {
      "command": "openrouter-multimodal",
      "env": { "OPENROUTER_API_KEY": "sk-or-v1-..." }
    }
  }
}
git clone https://github.com/stabgan/openrouter-mcp-multimodal.git
cd openrouter-mcp-multimodal
npm ci && npm run build
{
  "mcpServers": {
    "openrouter": {
      "command": "node",
      "args": ["/absolute/path/to/openrouter-mcp-multimodal/dist/index.js"],
      "env": { "OPENROUTER_API_KEY": "sk-or-v1-..." }
    }
  }
}
docker run --rm -i -e OPENROUTER_API_KEY=sk-or-v1-... stabgan/openrouter-mcp-multimodal:latest
{
  "mcpServers": {
    "openrouter": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-e",
        "OPENROUTER_API_KEY=sk-or-v1-...",
        "stabgan/openrouter-mcp-multimodal:latest"
      ]
    }
  }
}

Use -i (interactive stdio). Avoid -t (TTY corrupts MCP framing on some hosts).

docker run --rm -i -e OPENROUTER_API_KEY=sk-or-v1-... \
  ghcr.io/stabgan/openrouter-mcp-multimodal:5.0.1
{
  "mcpServers": {
    "openrouter": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-e",
        "OPENROUTER_API_KEY=sk-or-v1-...",
        "ghcr.io/stabgan/openrouter-mcp-multimodal:5.0.1"
      ]
    }
  }
}

Interactive install (writes config for your client):

npx -y @smithery/cli install @stabgan/openrouter-mcp-multimodal --client claude
# or: --client cursor | vscode | windsurf | ...

Listing: smithery.ai/server/@stabgan/openrouter-mcp-multimodal

Official name: io.github.stabgan/openrouter-multimodal

Clients that support registry-driven install will offer npm or Docker; otherwise use the JSON blocks above.

claude mcp add openrouter -- npx -y @stabgan/openrouter-mcp-multimodal
# project scope:
claude mcp add --scope project openrouter -- npx -y @stabgan/openrouter-mcp-multimodal

Set OPENROUTER_API_KEY in your shell or client env before starting Claude Code.

Debug tools/list and tool calls against a live OpenRouter key:

export OPENROUTER_API_KEY=sk-or-v1-...
npx -y @modelcontextprotocol/inspector npx -y @stabgan/openrouter-mcp-multimodal

When Claude Desktop or Cursor cannot find npx (GUI apps often miss shell PATH), wrap with cmd:

{
  "mcpServers": {
    "openrouter": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@stabgan/openrouter-mcp-multimodal"],
      "env": { "OPENROUTER_API_KEY": "sk-or-v1-..." }
    }
  }
}

If still failing, use the full path from where npx as the command.

Why this server?

Capability

This server

Typical MCP LLM servers

Text chat (300+ models)

✅

✅

Image analysis + generation

✅

partial

Audio analysis + TTS

✅

❌

Video analysis + generation

✅

❌

Model search / validate / rerank

✅

❌

Path sandbox + SSRF protection

✅

rare

MCP 2025 structured outputs

✅

rare

Async video + progress notifications

✅

❌

Tools

19 MCP tools. Each description includes Use when, Good/Bad examples, Fails when, and Works with so agents pick the right tool and recover from errors.

Tool

Purpose

chat_completion

Text chat, web search, provider routing, caching, reasoning

start_chat_completion

Async background job for long-running reasoning models

get_chat_completion_status

Poll / retrieve async completion results

analyze_image

Vision — local path, URL, or data URL + question

analyze_audio

Transcribe / analyze audio files

analyze_video

Describe / Q&A over video files

generate_image

Text-to-image via chat completions with reference images

generate_image_dedicated

Text-to-image via dedicated /api/v1/images (resolution, quality, format)

generate_audio

Text-to-speech / music via chat completions

text_to_speech

Dedicated TTS (/api/v1/audio/speech) — free Deepgram default, voices, speed, mp3/pcm

speech_to_text

Dedicated STT (/api/v1/audio/transcriptions) — Whisper, GPT-4o

generate_video

Text-to-video (async, resumable)

generate_video_from_image

Image-to-video (narrower schema)

get_video_status

Poll / resume video jobs

search_models

Paginated model catalog search

get_model_info

Pricing, context, modalities

validate_model

Cheap model ID existence check

rerank_documents

Relevance ranking for RAG

health_check

API key + reachability probe

Errors use a closed _meta.code taxonomy: INVALID_INPUT · UNSAFE_PATH · UPSTREAM_* · MODEL_NOT_FOUND · JOB_STILL_RUNNING · and more.

Binary tool results (v4.7.0+)

Generate tools (generate_image, generate_image_dedicated, generate_audio, text_to_speech, generate_video, generate_video_from_image, get_video_status) return image, audio, or video bytes. As of 4.7.0 the behavior is explicit:

save_path

Tool result

Set

Text pointer only — e.g. Image saved to: out.png (… bytes, image/png) plus _meta.save_path. No inline base64 (avoids duplicating large payloads in the MCP channel).

Unset, under byte ceiling

Inline media block and summary text (images/audio use MCP image / audio types; video uses MCP resource blocks).

Unset, over ceiling

Text only with a hint to pass save_path.

Default inline ceilings (override per kind or globally):

Kind

Default

Env vars (precedence: per-kind → global)

Image

1 MiB

OPENROUTER_IMAGE_INLINE_MAX_BYTES → OPENROUTER_INLINE_MAX_BYTES

Audio

1 MiB

OPENROUTER_AUDIO_INLINE_MAX_BYTES → OPENROUTER_INLINE_MAX_BYTES

Video

10 MiB

OPENROUTER_VIDEO_INLINE_MAX_BYTES → OPENROUTER_INLINE_MAX_BYTES

If you previously relied on both a saved file and inline media in the same tool result, read the file from _meta.save_path (or omit save_path to get inline media when under the ceiling).

Examples

Chat (free model)

{
  "tool": "chat_completion",
  "arguments": {
    "model": "google/gemma-4-26b-a4b-it:free",
    "messages": [{ "role": "user", "content": "Summarize MCP in one sentence." }]
  }
}

Analyze an image

{
  "tool": "analyze_image",
  "arguments": {
    "image_path": "diagram.png",
    "question": "List every label in this diagram."
  }
}

Use image_path and question — not image / prompt.

Search models (vision + free)

{
  "tool": "search_models",
  "arguments": {
    "query": "gemma",
    "capabilities": { "vision": true },
    "limit": 10,
    "offset": 0
  }
}

Generate video (async)

{
  "tool": "generate_video",
  "arguments": {
    "model": "google/veo-3.1",
    "prompt": "Ocean waves at sunrise, cinematic drone shot",
    "duration": 4,
    "save_path": "river.mp4"
  }
}

If the job is still running when max_wait_ms elapses, the response succeeds with _meta.code: JOB_STILL_RUNNING and a video_id — call get_video_status to resume. This is not an error.

With save_path set (as above), the result is a text pointer to the saved file once complete — not inline video. See Binary tool results.

More examples: docs/plans/tool-description-improvement.md

Security

  • Input path sandbox — local paths on analyze_* and reference images must stay inside OPENROUTER_INPUT_DIR (falls back to OPENROUTER_OUTPUT_DIR, then cwd)

  • Output path sandbox — save_path must stay inside OPENROUTER_OUTPUT_DIR

  • Async job reads — get_chat_completion_status resolves disk paths only under OPENROUTER_OUTPUT_DIR/openrouter-jobs/ (4.7.0+)

  • SSRF protection — private/reserved IPs blocked on URL fetches

  • Untrusted content — analyze outputs tagged _meta.content_is_untrusted: true

Override sandboxes only with OPENROUTER_ALLOW_UNSAFE_PATHS=1 (discouraged).

Report vulnerabilities: SECURITY.md (private disclosure — do not file public issues for exploits).

Configuration

Variable

Required

Default

Description

OPENROUTER_API_KEY

Yes

—

OpenRouter API key

OPENROUTER_DEFAULT_MODEL

No

google/gemma-4-26b-a4b-it:free

Default when tools omit model

OPENROUTER_OUTPUT_DIR

No

cwd

Sandbox root for save_path

OPENROUTER_INPUT_DIR

No

OUTPUT_DIR or cwd

Sandbox root for local input files

OPENROUTER_INLINE_MAX_BYTES

No

1048576 (image/audio)

Global inline media ceiling

OPENROUTER_IMAGE_INLINE_MAX_BYTES

No

falls back to global

Per-kind inline ceiling

OPENROUTER_AUDIO_INLINE_MAX_BYTES

No

falls back to global

Per-kind inline ceiling

OPENROUTER_VIDEO_INLINE_MAX_BYTES

No

10485760

Video inline ceiling

OPENROUTER_LOG_LEVEL

No

info

error / warn / info / debug

See .env.example for the full list (provider routing, fetch limits, caching, video polling, async jobs, integration-test overrides).

Development

git clone https://github.com/stabgan/openrouter-mcp-multimodal.git
cd openrouter-mcp-multimodal
npm install
cp .env.example .env   # add OPENROUTER_API_KEY
npm run build

Testing

Command

What it runs

npm test

1018 unit + mock tests (no API key, <20s)

npm run test:regression

Security + schema regression guards

npm run test:integration

16 live OpenRouter scenarios (requires .env key)

npm run test:e2e

Full MCP stdio smoke (scripts/live-e2e.mjs)

npm run ci

lint + format + build + all of the above except e2e

Free models for CI / zero-credit accounts: integration tests default to google/gemma-4-26b-a4b-it:free (override with OPENROUTER_INTEGRATION_MODEL). GitHub Actions requires the OPENROUTER_API_KEY repository secret.

Mock tests live under src/__tests__/mock/ and cover handlers, path sandboxes, SSRF blocks, model-cache pagination, tool descriptions, and structured outputs — 330+ additional cases beyond the core suite.

npm run lint
npm run format:check
npm run version:check   # package.json vs src/version.ts, server.json, pyproject.toml

Releasing

Published artifacts (npm, PyPI/uvx, Docker, GHCR) all ship from the same semver on a git tag (vX.Y.Z). Pushing to main runs tests but does not publish to npm or PyPI.

Normal flow: merge conventional commits to main → Release Please opens a Release PR → merge it → tag is created → CI publishes everywhere.

Manual flow: bump all version files → npm run version:check → npm run ci + smoke tests → commit → git tag vX.Y.Z → git push origin vX.Y.Z.

Full checklist, file list, CI secrets, and agent instructions:

Troubleshooting

Symptom

Likely cause

Fix

Server exits immediately / OPENROUTER_API_KEY is required

Missing or empty API key

Set OPENROUTER_API_KEY in client env or shell — get one at openrouter.ai/keys

_meta.code: INVALID_CREDENTIALS or HTTP 401

Bad or revoked key

Regenerate at openrouter.ai/keys; restart the MCP client

_meta.code: MODEL_NOT_FOUND

Typo or retired model ID

Run search_models or validate_model; check openrouter.ai/models

HTTP 402 / insufficient credits

Paid model or generation on zero balance

Add credits at openrouter.ai/credits or use a :free model

_meta.code: UPSTREAM_HTTP with 429

Rate limit

Wait for _meta.retry_after_seconds if present; reduce concurrency

_meta.code: UNSAFE_PATH

Local path outside sandbox

Put files under OPENROUTER_INPUT_DIR or set OPENROUTER_OUTPUT_DIR wider; see Security

npx not found (Windows GUI apps)

GUI PATH differs from terminal

Use the Windows npx cmd /c wrapper

No inline image/audio after upgrade

v4.7.0 with save_path set

Expected — result is text + _meta.save_path only; omit save_path or read the saved file

MCP client shows stale tool list

Client cache

Restart MCP / reload window after upgrading the package pin

Structured errors include _meta.suggestions with agent-oriented next steps when available.

FAQ

Do I need paid OpenRouter credits?

No, to get started. Free models work for chat and vision. Audio/video generation usually requires credits; analysis may return 402 on some models — the server surfaces that as a structured error.

Which MCP clients are supported?

Any MCP-compatible client over stdio: Cursor, Claude Desktop, VS Code Copilot, Windsurf, Cline, Kiro, and custom agents.

How is this different from calling OpenRouter directly?

This server adds MCP tool schemas, security sandboxes, error taxonomy, model caching, async video polling with progress notifications, and agent-oriented tool descriptions — so LLMs invoke the right capability without custom HTTP glue.

Where is the security advisory for path traversal?

Fixed in 4.5.2+ — see GHSA-3q7p-736f-x44v, SECURITY.md, and docs/solutions/security-issues/.

Compatibility

Works with any MCP client. Protocol: MCP 2025-06-18. Node ≥ 22 (Docker image uses Node 24).

License

Apache 2.0 — see LICENSE.

Contributing

Issues and PRs welcome. For large changes, open an issue first.

Before submitting: run npm run ci. Use Conventional Commits (fix:, feat:, etc.) so Release Please can cut the next release. See docs/RELEASING.md if you need to ship a version.

Available Tools

11 tools
analyze_audioB
Read-only

Analyze or transcribe an audio file using a multimodal model

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNo
questionNoQuestion or instruction about the audio (default: transcribe)
audio_pathYesFile path, URL, or data URL (base64-encoded audio)

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description adds limited behavioral insight beyond stating 'analyze or transcribe'. It does not disclose limitations like supported formats, file sizes, or any side effects, but there is no contradiction with annotations.

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, concise sentence with no redundant words. It effectively communicates the core function without unnecessary elaboration.

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?

The description does not explain the return format or output structure, and no output schema is provided. It also omits details about supported audio formats, maximum file size, or any behavioral constraints. Given the tool's complexity, this is a significant gap.

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 adds value for the 'question' parameter by noting an optional instruction with a default of 'transcribe', which is beyond the schema. However, the 'model' parameter lacks any description in the schema and is not addressed in the description. With 67% schema coverage, the description partially compensates.

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: analyzing or transcribing an audio file. It specifies the verb ('analyze or transcribe') and the resource ('audio file'), and the name 'analyze_audio' distinguishes it from sibling tools like 'analyze_image' and 'analyze_video'.

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 on when to use this tool versus alternatives. There is no mention of prerequisites, scenarios where transcription vs. analysis is appropriate, or exclusions. The sibling list includes 'generate_audio' but no context for choosing between them.

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

analyze_imageB
Read-only

Analyze an image using a vision model

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNo
questionNoQuestion about the image
image_pathYesFile path, URL, or data URL

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that it uses a vision model, but does not disclose performance characteristics, required permissions, or output format. It provides minimal behavioral context beyond annotations.

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, front-loaded sentence with no redundancy. Every word contributes to clarity, making it highly efficient.

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 output schema, the description should hint at the return type (e.g., text, structured data). It also omits limitations like image size or supported formats. The tool is simple, but the description is too sparse for complete 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 67% (2 of 3 parameters have descriptions). The tool description adds no additional meaning beyond the schema, so it meets the baseline expectation without improvement.

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 'Analyze an image using a vision model' clearly specifies a verb (analyze) and resource (image), and distinguishes it from sibling tools like analyze_audio and analyze_video.

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 on when to use this tool versus alternatives such as generate_image or when not to use it. The description lacks any usage context or conditions.

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

analyze_videoA
Read-only

Analyze or transcribe a video file using a multimodal model. Accepts mp4, mpeg, mov, or webm from a local file path, HTTP(S) URL, or base64 data URL. Default model: google/gemini-2.5-flash.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNoOverride the model ID.
questionNoQuestion or instruction about the video (default: describe).
video_pathYesFile path, HTTP(S) URL, or base64 data URL. Supported formats: mp4, mpeg, mov, webm.

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds format details and default model but does not disclose behavioral traits like output format or side effects. Description is consistent with annotations but adds limited value beyond them.

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 two sentences: first stating purpose, second covering formats and default model. No unnecessary information, though the structure could be slightly improved by front-loading the most critical info.

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?

With no output schema, the description should clarify what the tool returns (e.g., transcription or analysis text). It lacks this, and omits guidance on the 'question' parameter's behavior versus the default. Overall, it covers input basics but is incomplete regarding expected output.

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 coverage is 100% with detailed descriptions for all three parameters. The description adds the default model ('google/gemini-2.5-flash'), which is not in the schema, providing useful context. The rest of the parameter info is already covered by the schema.

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 analyzes or transcribes a video file using a multimodal model, specifies supported formats (mp4, mpeg, mov, webm), and mentions a default model. This distinguishes it from sibling tools like analyze_audio and analyze_image, which target other modalities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for video content via the resource name and accepted formats, but does not explicitly state when to use this tool over alternatives or provide exclusions. The context is clear, but guidance is implicit.

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

chat_completionB

Send messages to an OpenRouter model and get a response

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNoModel ID (optional, uses default)
messagesYes
max_tokensNo
temperatureNo

TDQS

B3.2/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds no extra behavioral context such as token consumption, cost, or response format. For a mutation tool, this is insufficient 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 a single, clear sentence with no extraneous information. It is front-loaded with the core action, but could benefit from mentioning key parameters.

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?

The tool has multiple parameters and nested objects, but the description omits details on response format, error handling, streaming, or any limitations. Without an output schema, the description should provide more context to be complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is low (25%), and the description does not explain individual parameters like temperature or max_tokens. It only implies 'model' and 'messages' are used. The description fails to compensate for the schema's lack of detail.

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 verb 'Send messages' and the resource 'OpenRouter model', directly conveying the tool's function. It distinguishes from sibling tools like analyze_audio or generate_image, which have different modalities.

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?

No explicit guidance on when or when not to use this tool versus alternatives. The verb 'chat' implies it is for conversational interactions, but no mention of situations where other tools (e.g., analyze_image) would be more appropriate.

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

generate_audioA

Generate audio from a text prompt. Conversational models (e.g. openai/gpt-audio) respond in spoken audio. Music models (e.g. google/lyria-3-clip-preview) need a structured prompt. Output format is auto-detected and file extension is corrected automatically.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNoModel ID (default: openai/gpt-audio)
voiceNoVoice name (default: alloy)
formatNoRequested format: pcm16 (default), mp3, flac, opus
promptYesText input
save_pathNoOptional path to save the audio. Extension auto-corrected and routed through OPENROUTER_OUTPUT_DIR sandbox.

TDQS

A4.2/5.0
Behavior3/5

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

Annotations are minimal (readOnlyHint=false, etc.), and the description adds behavioral info like auto-detection and file extension correction, but does not disclose potential side effects, permissions, or rate limits.

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?

Three concise sentences with no fluff, front-loaded with main purpose, and each sentence adds distinct value.

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 5 parameters, no output schema, and minimal annotations, the description covers core functionality and parameter nuances well, though could mention what the tool returns (e.g., audio data or saved path).

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 coverage is 100%, but the description adds context beyond schema: explains prompt structure for music models, notes defaults for model/voice, and describes auto-correction for save_path.

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 generates audio from text, specifying two model categories (conversational vs music) and auto-detection of output format. It distinguishes between use cases effectively.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance on using conversational vs music models and mentions auto-detection of format, but does not explicitly exclude alternatives or compare with sibling tools like analyze_audio.

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

generate_imageA

Generate an image from a text prompt. Optionally conditioned on one or more reference images (file paths, http(s) URLs, or data URLs) for character / style consistency. Sends modalities: ["image","text"] by default; override via the modalities field if needed.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNo
promptYes
save_pathNoOptional path to save the image. Routed through the OPENROUTER_OUTPUT_DIR sandbox.
image_sizeNoOutput resolution bucket. 1K is the default; 0.5K / 2K / 4K are model-dependent.
max_tokensNoCap on completion tokens. Defaults to the model context window, which can trip free-tier quotas; set e.g. 4096 on low-credit accounts.
modalitiesNoOverride the default `modalities: ["image","text"]` sent to OpenRouter. Most callers should leave this unset. Provide e.g. ["text"] to suppress image output for inspection / captioning.
aspect_ratioNoOutput aspect ratio (e.g. 1:1, 16:9, 9:16, 4:3, 3:4, 21:9). Model-dependent.
input_imagesNoOptional reference images for visual consistency. Each entry may be a local file path (sandboxed to OPENROUTER_INPUT_DIR / OPENROUTER_OUTPUT_DIR / cwd), an http(s) URL, or a `data:image/...;base64,...` URL. Inlined as multimodal user content in the order given.

TDQS

A4.4/5.0
Behavior4/5

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

Discloses default modalities and ability to override, plus reference image formats. Adds context beyond annotations (which are neutral). Could mention non-destructive nature, but not necessary.

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?

Three well-front-loaded sentences with zero waste. Every sentence adds value.

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?

Covers main functionality, conditioning, and modality override. Lacks explicit return format, but 'generate an image' implies output. Adequate for tool complexity.

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?

Adds meaning beyond schema by explaining input_images purpose (character/style consistency) and modalities override. Schema coverage is high, but description provides useful context.

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?

Clearly states it generates an image from a text prompt, with optional conditioning on reference images. Distinct from sibling tools like analyze_audio or chat_completion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies when to use reference images for consistency hints, and mentions modality override. Lacks explicit when-not or alternatives, but sibling tools are clearly different in modality.

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

generate_videoA

Generate a video from a text prompt using an OpenRouter video-generation model (default: google/veo-3.1). Submits an async job, polls until completion or max_wait_ms, then downloads the result. Optionally conditioned on first/last-frame images or reference images. Large outputs are auto-saved when save_path is provided and path-sandboxed.

ParametersJSON Schema
NameRequiredDescriptionDefault
seedNoDeterministic seed when supported.
modelNoOverride the video model ID.
promptYesText description of the desired video.
durationNoDuration in seconds (model-dependent).
providerNoProvider-specific passthrough options keyed by provider slug.
save_pathNoWhere to save the video. Routed through the OPENROUTER_OUTPUT_DIR sandbox; extension auto-corrected.
resolutionNo480p / 720p / 1080p / 1K / 2K / 4K (model-dependent).
max_wait_msNoTotal time to wait for the async job before returning a resumable handle (default 600000 ms).
aspect_ratioNo16:9 / 9:16 / 1:1 / 4:3 / 3:4 / 21:9 / 9:21 (model-dependent).
last_frame_imageNoOptional image used as the last frame for frame transitions.
poll_interval_msNoPolling cadence (default 15000 ms).
reference_imagesNoOptional style/content reference images.
first_frame_imageNoOptional image (path, URL, or data URL) used as the first frame for image-to-video.

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the annotations (which are all false), the description discloses async job submission, polling, timeout handling, auto-saving with path sandboxing, and image conditioning. No contradictions with annotations.

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 paragraph of four sentences, efficiently covering the main action and key details. It could be slightly more structured with bullet points, but no information is wasted.

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's complexity (13 parameters, async behavior, optional images, sandboxing), the description covers the essential workflow: async submission, polling, auto-save, and sandbox. It does not explain return values or error handling details, but no output schema exists.

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 coverage is 100%, but the description adds meaningful context: default model, model-dependent constraints on resolution/duration, and auto-corrected save path extension. This adds value beyond the schema alone.

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 it generates a video from a text prompt using an OpenRouter model, and it distinguishes itself from sibling tools like generate_audio and generate_image by specifying video generation with async polling and optional image conditioning.

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 video generation but does not explicitly state when to use this tool vs alternatives (e.g., get_video_status for status checks, analyze_video for analysis). No 'when not to use' guidance is provided.

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

get_model_infoC
Read-onlyIdempotent

Get details about a specific model

ParametersJSON Schema
NameRequiredDescriptionDefault
modelYes

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which cover the behavioral profile. The description adds no additional behavioral context beyond stating it retrieves details, so it meets the baseline but does not exceed annotations.

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 concise sentence with no redundant words. However, it is slightly too brief and could benefit from additional context without becoming verbose.

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 output schema and a single parameter, the description should at least hint at what kind of details are returned (e.g., capabilities, metadata). The current description is too minimal to fully inform an agent about the tool's output or usage prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one parameter 'model' with no description, and the tool description does not clarify what the parameter expects (e.g., model name, ID, or exact string). With 0% schema description coverage, the description should compensate but fails to add meaning.

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 gets details about a specific model, which distinguishes it from siblings like search_models (searching for models) and other generation tools. However, it does not specify what constitutes 'details', leaving some ambiguity.

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 search_models, nor does it mention when to avoid using it. No context or exclusions are given.

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

get_video_statusA
Read-onlyIdempotent

Resume a previously submitted video generation job by id. Returns the latest status; if completed, downloads the video (and saves it when save_path is provided).

ParametersJSON Schema
NameRequiredDescriptionDefault
video_idYesJob id from a previous generate_video call.
save_pathNoOptional save path (applies when the job is already completed).

TDQS

A4.1/5.0
Behavior4/5

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

Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it returns latest status and downloads the video if completed, which provides behavioral context beyond annotations. No contradiction.

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?

Single sentence, front-loaded with the primary action, no unnecessary words. Every part earns its place.

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?

While the description covers the completion case, it omits what happens when the job is still running (e.g., returns status only). No output schema to supplement, leaving a gap for incomplete jobs.

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?

Input schema has 100% coverage with descriptions for video_id and save_path. The description reiterates the save_path usage but does not add new semantic value beyond the schema.

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 action: 'Resume a previously submitted video generation job by id.' It specifies the resource (video generation job) and distinguishes from siblings like generate_video and analyze_video.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage after a generate_video call, but does not explicitly state when not to use it or mention alternatives. It is clear enough for an agent to infer context.

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

search_modelsC
Read-onlyIdempotent

Search available OpenRouter models

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryNo
providerNo
capabilitiesNo

TDQS

C2/5.0
Behavior2/5

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

Annotations already declare the tool as read-only, non-destructive, and idempotent. The description adds no further behavioral context, such as how the search is performed, pagination behavior, or any limitations (e.g., maximum results). With annotations covering safety, the description does not extend transparency beyond what is already inferred.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The description is extremely concise (one sentence) but lacks substance. While brevity is valued, it omits critical details such as what the search filters are or how results are returned. The single sentence does not fully earn its place as it fails to inform adequate use.

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

Completeness1/5

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

Given the tool has 4 parameters (including a nested object) and no output schema, the description is severely incomplete. It does not clarify the search behavior (e.g., whether 'query' is a free-text search or exact match), the effect of 'provider' and 'capabilities' filters, or the structure of results. An agent cannot reliably invoke this tool based solely on the current description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain the parameters. It does not mention 'query', 'provider', 'capabilities', or 'limit' at all, leaving the agent to infer their meaning from names alone. The nested 'capabilities' object further complicates usage without documentation.

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

Purpose3/5

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

The description 'Search available OpenRouter models' clearly indicates the tool's purpose: searching models on OpenRouter. However, it does not distinguish this from sibling tools like 'get_model_info' or 'validate_model', which also deal with models. A more specific description (e.g., listing all searchable criteria) would improve 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?

No guidance is provided on when to use this tool versus alternatives such as 'get_model_info' for retrieving a specific model's details. The description offers no context about prerequisites, expected input patterns, or scenarios where search is preferred.

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

validate_modelA
Read-onlyIdempotent

Check if a model ID exists

ParametersJSON Schema
NameRequiredDescriptionDefault
modelYes

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnly and idempotent, so description adds no extra behavioral context (e.g., return type for non-existence, error handling). Adequate but no added value beyond annotations.

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?

Single concise sentence, front-loaded with verb and purpose. No redundant words.

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?

Simple tool but absence of output schema means description should clarify return type (e.g., boolean). It doesn't, leaving ambiguity about the response for non-existent models.

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?

With 0% schema description coverage, description adds crucial context that the 'model' parameter is an ID. Still lacks format or validation hints, but compensates partially.

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?

Description clearly states the tool checks existence of a model ID, which is a distinct purpose from siblings like get_model_info (retrieves details) and search_models (lists 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 guidance on when to use this vs alternatives (e.g., get_model_info for details, search_models for browsing). Does not specify prerequisites or context.

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. 7 tool updatesv1.8.3
    • Addedanalyze_audio
    • Addedanalyze_video
    • Addedgenerate_audio
    • Changedgenerate_image6 fields changed
      • addedInput schema / properties / aspect_ratio
        Added value: +{
+  "description": "Output aspect ratio (e.g. 1:1, 16:9, 9:16, 4:3, 3:4, 21:9). Model-dependent.",
+  "enum": [
+    "1:1",
+    "2:3",
+    "3:2",
+    "3:4",
+    "4:3",
+    "4:5",
+    "5:4",
+    "9:16",
+    "16:9",
+    "21:9",
+    "1:4",
+    "4:1",
+    "1:8",
+    "8:1"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / image_size
        Added value: +{
+  "description": "Output resolution bucket. 1K is the default; 0.5K / 2K / 4K are model-dependent.",
+  "enum": [
+    "0.5K",
+    "1K",
+    "2K",
+    "4K"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / input_images
        Added value: +{
+  "description": "Optional reference images for visual consistency. Each entry may be a local file path (sandboxed to OPENROUTER_INPUT_DIR / OPENROUTER_OUTPUT_DIR / cwd), an http(s) URL, or a `data:image/...;base64,...` URL. Inlined as multimodal user content in the order given.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • addedInput schema / properties / max_tokens
        Added value: +{
+  "description": "Cap on completion tokens. Defaults to the model context window, which can trip free-tier quotas; set e.g. 4096 on low-credit accounts.",
+  "minimum": 1,
+  "type": "number"
+}
      • addedInput schema / properties / modalities
        Added value: +{
+  "description": "Override the default `modalities: [\"image\",\"text\"]` sent to OpenRouter. Most callers should leave this unset. Provide e.g. [\"text\"] to suppress image output for inspection / captioning.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • addedInput schema / properties / save_path / description
        Added value: +"Optional path to save the image. Routed through the OPENROUTER_OUTPUT_DIR sandbox."
    • Addedgenerate_video
    • Addedget_video_status
    • Changedsearch_models2 fields changed
      • addedInput schema / properties / capabilities / properties / audio
        Added value: +{
+  "type": "boolean"
+}
      • addedInput schema / properties / capabilities / properties / video
        Added value: +{
+  "type": "boolean"
+}
  2. 6 tool updatesv1.8.2
    • First observedanalyze_image
    • First observedchat_completion
    • First observedgenerate_image
    • First observedget_model_info
    • First observedsearch_models
    • First observedvalidate_model
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Scored across 11 tools

Disambiguation5/5

Each tool targets a distinct function: analyzing audio/image/video, generating content, chat completions, and model queries. No two tools have overlapping purposes, and even the video generation status tool is clearly a helper for async workflows.

Naming Consistency4/5

Most tools follow a verb_noun pattern (analyze_, generate_, get_, search_, validate_). The exception is 'chat_completion', which combines two nouns rather than a verb_noun, causing a minor inconsistency in the naming style.

Tool Count5/5

With 11 tools, the set covers all major modalities (audio, image, video, text) and supporting functions (model info, search, validation). The count is well-balanced—not excessive or too sparse for the server's multimodal purpose.

Completeness4/5

Core analysis, generation, and query tools are present. Some minor gaps exist (e.g., no explicit tool for listing all models, though search_models and get_model_info cover it). Overall, the surface is comprehensive for typical multimodal workflows.

Maintenance

ActivityMaintained
ResponsivenessSlow

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches