de es ru zh

mediamcp

Name: mediamcp
Author: legolev

by legolev

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Научите любого ИИ-агента создавать изображения и видео

mediamcp — это MCP-сервер, который соединяет вашего ИИ-ассистента — Claude Code, Claude Desktop, Cursor, Windsurf, VS Code или любой другой клиент с поддержкой MCP — с облачными медиамоделями (Gemini Flash Image, GPT-5 Image, Seedream, Veo, Sora, …) через OpenRouter или любой OpenAI-совместимый API.

npm version node >= 20 license: MIT

English | Русский

⭐ Баннер выше сгенерирован самим mediamcp — один вызов generate_image.

Сгенерированные файлы всегда сохраняются на диск (по умолчанию в ~/Pictures/mediamcp), а каждый ответ содержит абсолютный путь к файлу и небольшое встроенное превью — агент сразу видит, что у него получилось.

ИИ-агентам: инструкция по установке, оптимизированная специально для вас, лежит в llms-install.md.

Вам понадобится API-ключ OpenRouter — получить его можно на https://openrouter.ai/keys.

Быстрая установка

Claude Code

claude mcp add mediamcp -e OPENROUTER_API_KEY=sk-or-v1-YOUR_KEY -- npx -y mediamcp

Claude Desktop

Добавьте в claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json, Windows: %APPDATA%\Claude\claude_desktop_config.json) и перезапустите Claude Desktop:

{
  "mcpServers": {
    "mediamcp": {
      "command": "npx",
      "args": ["-y", "mediamcp"],
      "env": { "OPENROUTER_API_KEY": "sk-or-v1-YOUR_KEY" }
    }
  }
}

Cursor

Install MCP Server

Или добавьте в ~/.cursor/mcp.json:

{
  "mcpServers": {
    "mediamcp": {
      "command": "npx",
      "args": ["-y", "mediamcp"],
      "env": { "OPENROUTER_API_KEY": "sk-or-v1-YOUR_KEY" }
    }
  }
}

Windsurf

Добавьте в ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "mediamcp": {
      "command": "npx",
      "args": ["-y", "mediamcp"],
      "env": { "OPENROUTER_API_KEY": "sk-or-v1-YOUR_KEY" }
    }
  }
}

VS Code (GitHub Copilot)

Install in VS Code

Или добавьте в .vscode/mcp.json (ключ запрашивается отдельно и не попадает в файл):

{
  "servers": {
    "mediamcp": {
      "command": "npx",
      "args": ["-y", "mediamcp"],
      "env": { "OPENROUTER_API_KEY": "${input:openrouter-key}" }
    }
  },
  "inputs": [
    {
      "id": "openrouter-key",
      "type": "promptString",
      "password": true,
      "description": "OpenRouter API key (https://openrouter.ai/keys)"
    }
  ]
}

Related MCP server: mcp-media-engine

Что сможет делать ваш агент

После установки просто скажите агенту что-нибудь вроде «сгенерируй hero-изображение для моего лендинга, 16:9», «убери фон с logo.png», «сделай 8-секундное видео с океанскими волнами на закате» или «оживи logo.png в 4-секундное видео» (image-to-video). Агент сам выберет подходящий инструмент:

Инструмент	Что делает
`generate_image`	Текст → изображение (одно или несколько). Сохраняет на диск, возвращает путь и встроенное превью. Поддерживает `count` (до 4 вариаций), `aspect_ratio` и переопределение `model`.
`edit_image`	Существующее изображение (одно или несколько) + инструкция → отредактированное изображение. Принимает пути к файлам, `https://`- и `data:`-URL; несколько источников — для объединения изображений в одну композицию.
`generate_video`	Текст → видео или картинка → видео (асинхронная задача, обычно 1–5 минут). Передайте `first_frame_image`, чтобы оживить существующую картинку (image-to-video), `last_frame_image` — для финального кадра, или `reference_images` — как референс стиля. Нужна i2v-модель (`bytedance/seedance-2.0`, `bytedance/seedance-2.0-fast`, `google/veo-3.1`). Дожидается результата, сохраняет mp4, возвращает путь. При таймауте возвращает `polling_url`.
`check_video_status`	Возобновляет ожидание видеозадачи по `polling_url` / id; по готовности скачивает результат.
`list_models`	Выводит слаги и цены моделей с поддержкой изображений/видео — агент сможет сам подобрать модель.
`check_config`	Диагностика: наличие и валидность ключа, эндпоинт, значения по умолчанию, возможность записи в каталог вывода. Если что-то не работает — запускайте его первым.

Конфигурация

Всё настраивается через переменные окружения в блоке env конфигурации вашего MCP-клиента:

Переменная	По умолчанию	Назначение
`OPENROUTER_API_KEY`	—	Обязательна. Ваш ключ OpenRouter.
`MEDIAMCP_API_KEY`	—	Псевдоним `OPENROUTER_API_KEY` для эндпоинтов, отличных от OpenRouter; имеет приоритет, если заданы обе переменные.
`MEDIAMCP_BASE_URL`	`https://openrouter.ai/api/v1`	Корневой URL любого OpenAI-совместимого API.
`MEDIAMCP_MODEL`	`google/gemini-2.5-flash-image`	Слаг модели изображений по умолчанию.
`MEDIAMCP_VIDEO_MODEL`	`google/veo-3.1`	Слаг видеомодели по умолчанию.
`MEDIAMCP_OUTPUT_DIR`	`~/Pictures/mediamcp`	Куда сохранять сгенерированные файлы (`~/mediamcp`, если `~/Pictures` не существует).
`MEDIAMCP_TIMEOUT_MS`	`120000`	HTTP-таймаут на один запрос.
`MEDIAMCP_PREVIEW`	`true`	Возвращать встроенное превью вместе с каждым результатом (`false` — только пути).
`MEDIAMCP_PREVIEW_MAX_DIM`	`768`	Длинная сторона встроенного превью в пикселях.
`MEDIAMCP_SCHEMA_DIALECT`	`2020-12`	Диалект JSON Schema, в котором публикуются схемы инструментов. Значение `draft-7` отдаёт вывод MCP SDK как есть.

Использование другого провайдера

Укажите в MEDIAMCP_BASE_URL любой OpenAI-совместимый эндпоинт и задайте соответствующий ключ:

"env": {
  "MEDIAMCP_BASE_URL": "https://your-endpoint.example.com/v1",
  "MEDIAMCP_API_KEY": "your-key",
  "MEDIAMCP_MODEL": "your/image-model"
}

mediamcp сам определяет, какой формат API поддерживает эндпоинт: выделенный эндпоинт /images (OpenRouter), /images/generations (классический OpenAI) или chat/completions с поддержкой изображений — первый сработавший вариант запоминается.

Диагностика проблем

Попросите агента запустить инструмент check_config — он сообщит, что именно настроено неверно и как это исправить.
Ту же диагностику можно запустить из терминала: npx -y mediamcp --check (используются переменные окружения вашей оболочки).
Типичные проблемы:
- «No API key configured» — добавьте OPENROUTER_API_KEY в блок env записи сервера в конфигурации MCP-клиента (а не только в профиль оболочки) и перезапустите клиент.
- «Out of credits (HTTP 402)» — пополните баланс на https://openrouter.ai/credits.
- «Not found (HTTP 404) … for model» — неверный слаг модели; запустите list_models.
- В клиенте ничего не происходит — убедитесь, что установлен Node.js ≥ 20 (node --version).
- «Tool '…' has an invalid outputSchema … unsupported dialect» — клиент проверяет схемы только по JSON Schema 2020-12. mediamcp публикует 2020-12 по умолчанию, так что ошибка означает старую версию: обновитесь и убедитесь, что check_config показывает tool schema dialect: 2020-12.

Разработка

git clone https://github.com/legolev/mediamcp && cd mediamcp
npm install
npm run build       # сборка в dist/index.js
npm test            # юнит-тесты (vitest)
npm run inspect     # открыть MCP Inspector с собранным сервером

Лицензия

MIT

mcp-name: io.github.legolev/mediamcp

Available Tools

6 tools

check_configCheck mediamcp ConfigurationA

Read-only

Diagnose the mediamcp server setup: endpoint, API key presence and validity, default models, and output directory writability. Run this first when any other mediamcp tool fails.

ParametersJSON Schema

Name	Required	Description	Default
`ping`	No	Also verify the API key against the endpoint with a live request.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`api_key`	Yes	Masked key or 'not set'
`preview`	Yes
`version`	Yes
`base_url`	Yes
`problems`	Yes
`key_check`	No
`output_dir`	Yes
`image_model`	Yes
`video_model`	Yes
`api_key_source`	No
`output_dir_writable`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint; description adds details about what is checked (endpoint, API key validity, etc.) and clarifies the ping parameter triggers a live request, which is consistent 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?

Two concise sentences cover all necessary information: purpose and usage guidance, with zero wasted words.

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?

For a simple diagnostic tool with one parameter and an output schema, the description provides sufficient context about what it checks and when to use it; could optionally mention the output format but not necessary given output 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?

Schema coverage is 100% and the parameter description in the schema is identical to what the tool description adds; no additional 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 uses specific verb 'diagnose' and lists the resources checked (endpoint, API key, models, output directory), clearly distinguishing it from sibling tools like edit_image or generate_video.

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

Usage Guidelines5/5

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

Explicitly instructs to 'Run this first when any other mediamcp tool fails', providing clear when-to-use context and implying it's a diagnostic first step.

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

check_video_statusCheck Video StatusA

Idempotent

Check a previously started video generation job (from generate_video's polling_url or video id). If the job has completed, downloads the video, saves it to disk, and returns the absolute path.

ParametersJSON Schema

Name	Required	Description
`video_id`	No	Alternatively, the raw video job id.
`output_dir`	No	Directory to save into (absolute, or ~ for home). Defaults to the configured output directory.
`polling_url`	No	The polling_url returned by generate_video.
`filename_prefix`	No	Short label used in the saved filename, e.g. 'hero-banner'. Sanitized to letters, digits, dashes.

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	No	Absolute path of the saved video, when completed
`status`	Yes	completed \| pending \| in_progress \| timeout \| failed \| error
`message`	No
`video_id`	No
`polling_url`	No	Pass to check_video_status to resume waiting

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already indicate idempotent and non-readonly, but the description adds crucial behavior: downloading and saving to disk. It does not contradict annotations. Some additional context (e.g., what happens on failure) could improve transparency, but the provided info is sufficient.

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?

Two sentences, no filler. The key action (check, download, save, return) is front-loaded and concise.

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?

The tool is simple and the description covers the main workflow. With an output schema present, it need not detail return format. Missing error-handling info is a minor gap, but not critical for this straightforward tool.

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 has 100% parameter descriptions, so baseline is 3. The description adds value by clarifying that polling_url and video_id are alternative identifiers, which is not explicit in 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 uses a specific verb ('check') and resource ('video generation job'), and clearly distinguishes from its sibling generate_video by being a follow-up step. It states exactly what happens on 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?

The description implies usage context (after generate_video) and mentions the two ways to specify the job (polling_url or video id). However, it does not explicitly state when not to use it or compare with other sibling tools, leaving room for ambiguity.

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

edit_imageEdit ImageA

Edit or transform existing image(s) with a text instruction — restyle, add or remove elements, change background, or combine several images into one scene. The result is saved to disk and its absolute path is returned, along with a small inline preview.

ParametersJSON Schema

Name	Required	Description
`model`	No	Model slug, e.g. 'google/gemini-2.5-flash-image' or 'openai/gpt-5-image'. Omit to use the configured default. Call list_models to see options.
`images`	Yes	Source image(s): absolute file paths, file:// URLs, https:// URLs, or data: URLs. Pass several images for composition or style-transfer edits.
`prompt`	Yes	Instruction describing the edit, e.g. 'remove the background', 'make it night time', 'combine these two photos into one scene'.
`output_dir`	No	Directory to save into (absolute, or ~ for home). Defaults to the configured output directory.
`filename_prefix`	No	Short label used in the saved filename, e.g. 'hero-banner'. Sanitized to letters, digits, dashes.

Output Schema

ParametersJSON Schema

Name	Required	Description
`failed`	Yes	Error messages for variations that failed
`images`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Beyond annotations (readOnlyHint=false, etc.), the description adds that the result is saved to disk and absolute path is returned with a preview. It also clarifies that multiple images can be passed for composition, adding behavioral context.

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?

Two sentences: first describes what the tool does with examples, second describes the output. No wasted words, front-loaded with the key action and resource.

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

Completeness5/5

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

Given the output schema exists (implied), the description covers the output format. Parameter details are rich in the schema. The description is complete for an agent to understand when and how to use the tool, and the sibling list provides additional context.

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 value: examples for prompt, allowed URL types for images, default behavior for model and output_dir, and sanitization for filename_prefix. This adds meaning beyond the schema's property descriptions.

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 'edit or transform' and the resource 'existing image(s)', with specific examples like restyling, adding/removing elements, changing background, or combining images. It distinguishes itself from siblings like 'generate_image' (creates new) and 'generate_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 use when editing existing images with a text instruction, but does not explicitly state when not to use or suggest alternatives. The sibling list helps differentiate, but the description itself lacks explicit usage boundaries.

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

generate_imageGenerate ImageA

Generate one or more images from a text prompt using a cloud AI model. Every image is saved to disk and its absolute path is returned, along with a small inline preview. Use edit_image instead when starting from an existing image.

ParametersJSON Schema

Name	Required	Description
`count`	No	Number of variations to generate (1-4, parallel requests, billed per image).
`model`	No	Model slug, e.g. 'google/gemini-2.5-flash-image' or 'openai/gpt-5-image'. Omit to use the configured default. Call list_models to see options.
`prompt`	Yes	Detailed description of the desired result. Be specific about subject, style, lighting, composition.
`output_dir`	No	Directory to save into (absolute, or ~ for home). Defaults to the configured output directory.
`aspect_ratio`	No	Desired aspect ratio. Support varies by model; treated as a strong hint.
`filename_prefix`	No	Short label used in the saved filename, e.g. 'hero-banner'. Sanitized to letters, digits, dashes.

Output Schema

ParametersJSON Schema

Name	Required	Description
`failed`	Yes	Error messages for variations that failed
`images`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

The description adds key behavioral context beyond annotations: images are saved to disk, absolute path returned, and inline preview. It also hints at billing and parallel requests via parameter comments. But it doesn't fully detail network or model 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 three efficient sentences, front-loading the core purpose and immediately providing the sibling alternative. No excess text.

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

Completeness5/5

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

Given 6 parameters, 1 required, an output schema, and sibling tools, the description and schema together cover usage, constraints, and return values comprehensively. No gaps.

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?

All 6 parameters have descriptions in the input schema (100% coverage), so the description adds no additional parameter info. Baseline 3 is appropriate.

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 images from a text prompt using a cloud AI model, specifies the output (saved to disk with absolute path and preview), and distinguishes it from the sibling edit_image.

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

Usage Guidelines5/5

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

The description explicitly says when to use this tool (generate from prompt) and provides a direct alternative ('Use edit_image instead when starting from an existing image'), giving clear usage guidance.

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

generate_videoGenerate VideoA

Generate a video from a text prompt (async job: starts generation, then waits and polls). Video generation typically takes 1-5 minutes. The finished file is saved to disk and its absolute path is returned. If waiting times out, a polling_url is returned — pass it to check_video_status later instead of starting a new (billed) job.

ParametersJSON Schema

Name	Required	Description
`model`	No	Video model slug, e.g. 'google/veo-3.1' or 'openai/sora-2-pro'. Omit to use the configured default.
`prompt`	Yes	Detailed description of the desired result. Be specific about subject, style, lighting, composition.
`output_dir`	No	Directory to save into (absolute, or ~ for home). Defaults to the configured output directory.
`resolution`	No	Output resolution (model-dependent).
`aspect_ratio`	No	Desired aspect ratio. Support varies by model; treated as a strong hint.
`wait_seconds`	No	How long to wait for completion before returning a resumable polling_url.
`generate_audio`	No	Whether the clip should include generated audio.
`filename_prefix`	No	Short label used in the saved filename, e.g. 'hero-banner'. Sanitized to letters, digits, dashes.
`duration_seconds`	No	Clip length in seconds (model-dependent).

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	No	Absolute path of the saved video, when completed
`status`	Yes	completed \| pending \| in_progress \| timeout \| failed \| error
`message`	No
`video_id`	No
`polling_url`	No	Pass to check_video_status to resume waiting

TDQS

A4.5/5.0

Behavior5/5

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

Discloses async behavior, polling, disk persistence, absolute path return, and timeout/resume pattern. Annotations indicate side effects (openWorldHint true) and non-idempotent, which the description aligns with. No contradictions.

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 sentences: purpose, typical timing, and critical timeout handling. Front-loaded, no redundancy, every sentence adds unique value.

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

Completeness5/5

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

Given 9 parameters, schema coverage, and output schema involvement, the description covers the essential async workflow, timeout fallback, and output behavior. No gaps remain for agent invocation.

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 covers 100% of parameters with descriptions. Description adds no extra parameter details beyond the timeout/polling context. Baseline 3 is appropriate since schema already does the heavy lifting.

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 'Generate a video from a text prompt' and distinguishes async nature. Explicitly mentions sibling tool check_video_status for timeout handling, differentiating from other generation tools.

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?

Explains when to use (text-to-video generation) and what to do on timeout (use polling_url with check_video_status). Warns against restarting to avoid extra billing. Lacks explicit when-not-to-use guidance but covers the key alternative.

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

list_modelsList Media ModelsA

Read-only

List image- and video-capable model slugs available on the configured endpoint, with pricing where known. Use this to pick a model value for generate_image, edit_image, or generate_video.

ParametersJSON Schema

Name	Required	Description	Default
`refresh`	No	Bypass the 1h cache and re-query the endpoint.

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`models`	Yes
`source`	Yes	'live' = queried from the endpoint, 'curated' = built-in fallback

TDQS

A4.3/5.0

Behavior4/5

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

Annotations indicate readOnlyHint and openWorldHint, and the description adds that it uses a 1-hour cache which can be bypassed with the refresh parameter. This provides useful 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?

Two sentences, front-loaded with action and purpose, no wasted words. Efficiently conveys all necessary information.

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

Completeness5/5

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

Given the tool's low complexity (one optional param, output schema present), the description fully covers purpose, usage, and behavioral traits. It mentions pricing and cache behavior, which are valuable.

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 only parameter 'refresh' is already well-described in the schema as bypassing the cache. The description does not add additional meaning beyond what the schema provides, and schema coverage is 100%.

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 lists model slugs for image and video generation, with pricing. It distinguishes from siblings by explaining its use for picking a model for generate_image, edit_image, or generate_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 explicitly says when to use this tool: to select a model for specific generation tasks. It does not mention when not to use it, but the context is clear enough.

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.

6 tool updatesv0.1.1Jul 10, 2026
- First observedcheck_config
- First observedcheck_video_status
- First observededit_image
- First observedgenerate_image
- First observedgenerate_video
- First observedlist_models

Deploy Server

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

TDQS

A4.5/5.0

Scored 2026-07-10 20:15 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: config diagnostics, async video status polling, image editing, image generation, video generation, and model listing. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., check_config, generate_image, list_models), making it easy to predict the function.

Tool Count5/5

Six tools is appropriate for a media-focused server, covering configuration, generation, editing, status checking, and model discovery without being too many or too few.

Completeness4/5

Core media workflows (generate, edit, check status, list models, diagnose config) are covered. Missing a tool to list or delete previously generated files, but the surface is largely complete.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

OpenRouter AOAuth
ai.openrouter.mcp
The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.
AI & Machine Learning
221
clipkit A
dev.clipkit
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
Multimedia Processing Image & Video Processing
15216
mcp-veoOAuth
io.github.AceDataCloud
MCP server for Google Veo AI video generation
Multimedia Processing Image & Video Processing Entertainment & Media
23
Writingmate MCPOAuth
ai.writingmate
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
AI & Machine Learning Image & Video Processing
1

Related MCP Servers

mcp-fal
AI & Machine Learning Image & Video Processing
MohsenMousaviEyeline
F
license
A
quality
D
maintenance
An MCP server that exposes Fal.ai generative media models as tools for image and video generation, and running any Fal.ai model, callable by Claude and other MCP-compatible clients.
Updated 3 months ago (2026-06-01 15:20 UTC)
3
-
mcp-media-engine
Multimedia Processing AI & Machine Learning
Tr1ckyMag1ca1
A
license
A
quality
B
maintenance
MCP server for AI-powered image, audio, and video generation, enabling media creation directly from Claude, Cursor, and other MCP clients.
Updated 2 months ago (2026-07-14 15:20 UTC)
11
64
MIT
imagine-mcp
Image & Video Processing AI & Machine Learning
n24q02m
A
license
A
quality
A
maintenance
Production-grade MCP server for image and video understanding and generation across Gemini, OpenAI, and Grok.
Updated 4 hours ago (2026-09-12 06:59 UTC)
5
4
Apache 2.0
LemGen AI Design MCP
Image & Video Processing AI & Machine Learning Multimedia Processing
gptimage2prompts
A
license
A
quality
C
maintenance
Open-source MCP server for AI image and video creation, enabling prompt library search, prompt enhancement, and media generation from Claude Code, Cursor, and other MCP hosts.
Updated 2 months ago (2026-07-01 13:34 UTC)
8
MIT