de es ru zh

mediamcp

Name: mediamcp
Author: legolev

by legolev

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Bringen Sie jedem KI-Agenten bei, Bilder und Videos zu erstellen

mediamcp ist ein MCP-Server, der Ihren KI-Assistenten – Claude Code, Claude Desktop, Cursor, Windsurf, VS Code oder einen anderen MCP-fähigen Client – mit Cloud-Medienmodellen verbindet (Gemini Flash Image, GPT-5 Image, Seedream, Veo, Sora, …) über OpenRouter oder eine beliebige OpenAI-kompatible API.

npm version node >= 20 license: MIT

English | Deutsch

⭐ Das Banner oben wurde von mediamcp selbst erzeugt – ein einziger Aufruf von generate_image.

Generierte Dateien werden immer auf der Festplatte gespeichert (standardmäßig in ~/Pictures/mediamcp), und jede Antwort enthält den absoluten Pfad zur Datei sowie eine kleine eingebettete Vorschau – der Agent sieht sofort, was er erstellt hat.

An KI-Agenten: Eine speziell für Sie optimierte Installationsanleitung finden Sie in llms-install.md.

Sie benötigen einen OpenRouter-API-Schlüssel – Sie erhalten ihn unter https://openrouter.ai/keys.

Schnellinstallation

Claude Code

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

Claude Desktop

Fügen Sie Folgendes in claude_desktop_config.json ein (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json, Windows: %APPDATA%\Claude\claude_desktop_config.json) und starten Sie Claude Desktop neu:

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

Cursor

Install MCP Server

Oder fügen Sie Folgendes in ~/.cursor/mcp.json ein:

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

Windsurf

Fügen Sie Folgendes in ~/.codeium/windsurf/mcp_config.json ein:

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

VS Code (GitHub Copilot)

Install in VS Code

Oder fügen Sie Folgendes in .vscode/mcp.json ein (der Schlüssel wird separat abgefragt und landet nicht in der Datei):

{
  "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: imagine-mcp

Was Ihr Agent können wird

Nach der Installation sagen Sie dem Agenten einfach etwas wie „Erzeuge ein Hero-Bild für meine Landingpage, 16:9", „Entferne den Hintergrund von logo.png", „Erstelle ein 8-Sekunden-Video mit Meereswellen bei Sonnenuntergang" oder „Erwecke logo.png zu einem 4-Sekunden-Video" (Image-to-Video). Der Agent wählt selbst das passende Werkzeug aus:

Werkzeug	Funktion
`generate_image`	Text → Bild (eines oder mehrere). Speichert auf der Festplatte, gibt Pfad und eingebettete Vorschau zurück. Unterstützt `count` (bis zu 4 Variationen), `aspect_ratio` und `model`-Überschreibung.
`edit_image`	Vorhandenes Bild (eines oder mehrere) + Anweisung → bearbeitetes Bild. Akzeptiert Dateipfade, `https://`- und `data:`-URLs; mehrere Quellen – zum Zusammenfügen von Bildern zu einer Komposition.
`generate_video`	Text → Video oder Bild → Video (asynchrone Aufgabe, dauert in der Regel 1–5 Minuten). Übergeben Sie `first_frame_image`, um ein vorhandenes Bild zu animieren (Image-to-Video), `last_frame_image` für den letzten Frame oder `reference_images` als Stilreferenz. Erfordert ein i2v-Modell (`bytedance/seedance-2.0`, `bytedance/seedance-2.0-fast`, `google/veo-3.1`). Wartet auf das Ergebnis, speichert MP4, gibt den Pfad zurück. Bei Zeitüberschreitung wird `polling_url` zurückgegeben.
`check_video_status`	Setzt das Warten auf eine Videoaufgabe über `polling_url` / ID fort; lädt das Ergebnis nach Fertigstellung herunter.
`list_models`	Zeigt Slugs und Preise von Modellen mit Bild-/Videounterstützung an – der Agent kann so selbst ein Modell auswählen.
`check_config`	Diagnose: Vorhandensein und Gültigkeit des Schlüssels, Endpunkt, Standardwerte, Schreibbarkeit des Ausgabeverzeichnisses. Wenn etwas nicht funktioniert – führen Sie dieses Werkzeug zuerst aus.

Konfiguration

Alles wird über Umgebungsvariablen im env-Block der Konfiguration Ihres MCP-Clients eingestellt:

Variable	Standardwert	Zweck
`OPENROUTER_API_KEY`	—	Erforderlich. Ihr OpenRouter-Schlüssel.
`MEDIAMCP_API_KEY`	—	Alias für `OPENROUTER_API_KEY` für andere Endpunkte als OpenRouter; hat Priorität, wenn beide Variablen gesetzt sind.
`MEDIAMCP_BASE_URL`	`https://openrouter.ai/api/v1`	Basis-URL einer beliebigen OpenAI-kompatiblen API.
`MEDIAMCP_MODEL`	`google/gemini-2.5-flash-image`	Standard-Slug für das Bildmodell.
`MEDIAMCP_VIDEO_MODEL`	`google/veo-3.1`	Standard-Slug für das Videomodell.
`MEDIAMCP_OUTPUT_DIR`	`~/Pictures/mediamcp`	Wohin generierte Dateien gespeichert werden (`~/mediamcp`, falls `~/Pictures` nicht existiert).
`MEDIAMCP_TIMEOUT_MS`	`120000`	HTTP-Timeout pro Anfrage.
`MEDIAMCP_PREVIEW`	`true`	Eingebettete Vorschau zusammen mit jedem Ergebnis zurückgeben (`false` – nur Pfade).
`MEDIAMCP_PREVIEW_MAX_DIM`	`768`	Längste Seite der eingebetteten Vorschau in Pixeln.
`MEDIAMCP_SCHEMA_DIALECT`	`2020-12`	JSON-Schema-Dialekt, in dem Tool-Schemas veröffentlicht werden. Der Wert `draft-7` gibt die MCP-SDK-Ausgabe unverändert zurück.

Einen anderen Anbieter verwenden

Geben Sie in MEDIAMCP_BASE_URL einen beliebigen OpenAI-kompatiblen Endpunkt an und legen Sie den passenden Schlüssel fest:

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

mediamcp erkennt selbst, welches API-Format der Endpunkt unterstützt: dedizierter /images-Endpunkt (OpenRouter), /images/generations (klassisches OpenAI) oder chat/completions mit Bildunterstützung – die erste erfolgreiche Variante wird gespeichert.

Fehlerbehebung

Bitten Sie den Agenten, das Werkzeug check_config auszuführen – es teilt Ihnen mit, was falsch konfiguriert ist und wie Sie es beheben.
Dieselbe Diagnose können Sie im Terminal ausführen: npx -y mediamcp --check (es werden die Umgebungsvariablen Ihrer Shell verwendet).
Häufige Probleme:
- „No API key configured" – fügen Sie OPENROUTER_API_KEY zum env-Block des Servereintrags in der MCP-Client-Konfiguration hinzu (nicht nur im Shell-Profil) und starten Sie den Client neu.
- „Out of credits (HTTP 402)" – laden Sie Ihr Guthaben unter https://openrouter.ai/credits auf.
- „Not found (HTTP 404) … for model" – falscher Modell-Slug; führen Sie list_models aus.
- Im Client passiert nichts – stellen Sie sicher, dass Node.js ≥ 20 installiert ist (node --version).
- „Tool '…' has an invalid outputSchema … unsupported dialect" – der Client prüft Schemas nur gegen JSON Schema 2020-12. mediamcp veröffentlicht standardmäßig 2020-12. Der Fehler bedeutet also eine alte Version: Aktualisieren Sie und stellen Sie sicher, dass check_config tool schema dialect: 2020-12 anzeigt.

Entwicklung

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 с собранным сервером

Lizenz

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.

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

Output 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.

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

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.

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

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.

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

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.

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

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.

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

Output 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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

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

ActivityNo data

ResponsivenessSyncing

Resources

Related MCP Connectors

OpenRouter A
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
1
https://mcp.openrouter.ai/mcp
OneOver B
com.oneover
Chat, image, video, and audio models from many vendors behind one remote MCP server and one key.
AI & Machine Learning Image & Video Processing Audio Processing
181
https://api.oneover.com/functions/v1/mcp
clipkit A
dev.clipkit
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
Multimedia Processing Image & Video Processing
15219
https://www.clipkit.dev/mcp
mcp-veo
io.github.AceDataCloud
MCP server for Google Veo AI video generation
Multimedia Processing Image & Video Processing Entertainment & Media
23
https://veo.mcp.acedata.cloud/mcp

Related MCP Servers

mcp-media-engine
Multimedia Processing AI & Machine Learning
Tr1ckyMag1ca1
A
license
A
quality
C
maintenance
MCP server for AI-powered image, audio, and video generation, enabling media creation directly from Claude, Cursor, and other MCP clients.
Updated 4 months ago (2026-07-14 15:20 UTC)
11
43 npm
MIT
imagine-mcp
Image & Video Processing AI & Machine Learning
n24q02m
A
license
A
quality
F
maintenance
Production-grade MCP server for image and video understanding and generation across Gemini, OpenAI, and Grok.
Updated 2 months ago (2026-09-13 07:41 UTC)
5
259 PyPI
4
Apache 2.0
LemGen AI Design MCP
Image & Video Processing AI & Machine Learning Multimedia Processing
gptimage2prompts
A
license
A
quality
D
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 4 months ago (2026-07-01 13:34 UTC)
8
MIT
mcp_photo
afr13nd77
A
license
Not graded
quality
D
maintenance
MCP server for generating and editing images using OpenRouter API, with support for multiple models and dynamic model discovery. Runs in Docker and integrates with Claude Desktop via stdio transport.
Updated 4 months ago (2026-07-20 06:59 UTC)
MIT