What can you do with this server?

imagine-mcp is a multi-provider MCP server that enables AI agents to understand and generate images and videos across Gemini, OpenAI, and Grok. Understand (understand tool): Analyze, describe, classify, or reason over one or more image/video URLs using a text prompt. Supports mixed image+video in a single call (Gemini) or image-only (OpenAI/Grok). Configurable provider, quality tier, model, and max tokens. Generate (generate tool): * Images: Text-to-image or image-to-image editing/inpainting via reference_image_url, across Gemini Imagen, OpenAI gpt-image, and Grok Imagine. * Videos: Text-to-video or image-to-video (async — first call returns a job_id; poll for completion). Supports aspect ratio and duration settings. * Output as base64, file path, or both. Configure (config tool): Manage provider credentials, adjust runtime settings (log level, default provider/tier, cache TTL), clear the response cache, check server/provider status, and open the browser-based credential setup form. Help (help tool): Retrieve full Markdown documentation for any tool topic (understand, generate, or config). Key features include multi-provider auto-fallback, poor/rich quality tiers, disk-based response caching, and a degraded mode that starts even with no credentials (surfacing only providers with keys set).

Which integrations are available for this server?

Enables image and video understanding and generation using OpenAI's gpt-image model, including image-to-image editing and generation from text prompts.

How do I use imagine-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@imagine-mcp generate a photorealistic image of a cat wearing a spacesuit on Mars" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

imagine-mcp

by n24q02m

Overview Schema Source Related Servers Score Discussions Admin

Python

Hybrid

imagine-mcp

mcp-name: io.github.n24q02m/imagine-mcp

Image and video understanding + generation for AI agents -- across Gemini, OpenAI, and Grok.

codecov PyPI Docker License: Apache-2.0

Python FastMCP MCP semantic-release Renovate

Project	Tagline	Tag
agent-chat-plugin	Peer AI agents chat in a shared folder — no human relay, no orchestrator, wor...	Tooling
better-code-review-graph	Knowledge graph for token-efficient code reviews -- semantic search and call-...	MCP
better-drive	2-way Google Drive sync with .driveignore filter — rclone engine, Windows tray	Tooling
better-email-mcp	IMAP/SMTP email for AI agents -- read, send, organize folders, and manage att...	MCP
better-godot-mcp	Composite MCP server for Godot Engine -- 17 composite tools for AI-assisted g...	MCP
better-notion-mcp	Markdown-first Notion for AI agents -- pages, databases, blocks, and comments...	MCP
better-semantic-release	Drop-in python-semantic-release fork with built-in release-safety guards (orp...	Tooling
better-telegram-mcp	Telegram for AI agents -- messages, chats, media, and contacts across both bo...	MCP
better-workspace-mcp	Google Workspace MCP server (Docs/Drive/Calendar/Gmail/Sheets/Slides/Tasks/Ch...	MCP
claude-plugins	Claude Code plugin marketplace for the n24q02m MCP servers -- install web sea...	Marketplace
imagine-mcp	Image and video understanding + generation for AI agents -- across Gemini, Op...	MCP
jules-task-archiver	Chrome Extension for bulk operations on Jules tasks via batchexecute API -- a...	Tooling
mcp-core	Shared foundation for building MCP servers -- Streamable HTTP transport, OAut...	MCP
mnemo-mcp	Persistent AI memory with hybrid search and embedded sync. Open, free, unlimi...	MCP
qwen3-embed	Lightweight Qwen3 text embedding and reranking via ONNX Runtime and GGUF	Library
skret	Secrets without the server.	CLI
tacet	A self-distilling neuro-symbolic cascade that amortises LLM cost across knowl...	Tooling
web-core	Shared web infrastructure package for search, scraping, HTTP security, and st...	Library
wet-mcp	Open-source MCP server for AI agents: web search, content extraction, and lib...	MCP

Related MCP server: mcp-media-engine

Features

Multimodal understanding -- Describe, classify, or reason over images and videos (Gemini handles mixed image + video in one call)
Image generation -- Text-to-image and image-to-image (edit / inpaint) across Gemini Imagen, OpenAI gpt-image, Grok Imagine
Video generation -- Text-to-video and image-to-video (Gemini Veo 3.1, Grok Imagine Video)
3 providers x 2 tiers -- Same interface for gemini / openai / grok at poor (cheap/fast) or rich (high quality); swap via parameter
Open model passthrough -- Understanding routes through litellm; pass any provider/model, or configure an ordered model chain (no hardcoded catalog)
Degraded mode -- Server starts with zero credentials and surfaces remaining providers as you add keys
Response cache -- Disk-based caching of understand responses with configurable TTL
Dual transport -- pure stdio with provider env vars (default) or HTTP multi-user with paste-token relay form

Install

Run with uvx (no install step) or pull the container image:

# uvx -- recommended, runs the published PyPI package
uvx imagine-mcp

# Docker
docker run -it --rm ghcr.io/n24q02m/imagine-mcp:latest

Add it to an MCP client by pointing the client at the uvx imagine-mcp command and supplying at least one provider key (see Configuration):

{
  "mcpServers": {
    "imagine": {
      "command": "uvx",
      "args": ["imagine-mcp"],
      "env": { "GEMINI_API_KEY": "AIza..." }
    }
  }
}

For per-client snippets (Claude Code, Codex, Gemini CLI, Cursor, Windsurf) and the browser-based HTTP setup, see the Setup docs.

Install with an AI agent -- paste this to your AI coding agent:

Install MCP server imagine-mcp following the steps at https://raw.githubusercontent.com/n24q02m/claude-plugins/main/plugins/imagine-mcp/setup-with-agent.md

Smithery

imagine-mcp ships a smithery.yaml so it can be installed and run through Smithery. The entry launches the published PyPI package over stdio (uvx --python 3.13 imagine-mcp) with an empty config schema -- no setup fields are required at deploy time. Provider keys are supplied at runtime through the server's own credential flow (env vars in stdio mode, or the browser setup form in HTTP mode; see Configuration).

Configuration

Two transports (default stdio; opt into http with --http, MCP_TRANSPORT=http, or TRANSPORT_MODE=http):

stdio (default) -- single-user, reads credentials from env vars only. Exits if none of the three provider keys are set.
http -- HTTP daemon. Local self-host on 127.0.0.1 by default, or multi-user remote (per-JWT-sub credential isolation) when PUBLIC_URL + MCP_DCR_SERVER_SECRET are set. In HTTP mode credentials are entered through a browser form at /authorize.

Provider keys

All optional -- the server starts in degraded mode and surfaces whichever providers have a key. Set at least one.

Env var	Provider	Get a key at
`GEMINI_API_KEY`	Gemini (image + video)	aistudio.google.com/apikey
`OPENAI_API_KEY`	OpenAI (image)	platform.openai.com/api-keys
`XAI_API_KEY`	Grok / xAI (image + video)	console.x.ai

When a tool is called without an explicit provider, the first key present wins in the order XAI_API_KEY -> OPENAI_API_KEY -> GEMINI_API_KEY.

Model chains (optional)

Model choice passes straight through to litellm (understand) or the native provider SDK (generate) -- there is no hardcoded model catalog. Each chain is a CSV of litellm provider/model entries; the order is the fallback order.

Env var	Purpose
`UNDERSTAND_MODELS`	Ordered model chain for `understand` (litellm fallback). Empty and no explicit `model` -> `understand` fails loud (no built-in default).
`GENERATE_MODELS`	Ordered model chain for `generate`. The first entry selects the native provider + model. Empty -> the provider's own minimal built-in default.
`GENERATE_PROVIDER_PRIORITY`	CSV of provider names reordering generation auto-fallback. Defaults to `grok,openai,gemini`.

Understanding is routed through litellm (provider/model passthrough), so any litellm provider works -- supply that provider's <PROVIDER>_API_KEY. Generation stays on the native provider SDKs (Gemini, OpenAI, Grok). Example:

{
  "mcpServers": {
    "imagine": {
      "command": "uvx",
      "args": ["imagine-mcp"],
      "env": {
        "UNDERSTAND_MODELS": "gemini/<model-id>,openai/<model-id>",
        "GEMINI_API_KEY": "AIza...",
        "OPENAI_API_KEY": "sk-..."
      }
    }
  }
}

Runtime knobs

config(action="set", key=..., value=...) adjusts log_level, default_provider, default_tier, and cache_ttl_seconds at runtime.

CLI

The imagine-mcp console command installed by the package takes no subcommands -- it starts the MCP server directly. Transport is selected by a single flag or its environment-variable equivalents:

imagine-mcp            # stdio transport (default); reads provider keys from env vars
imagine-mcp --http     # HTTP daemon; credentials via the browser setup form

Invocation	Equivalent env	Result
`imagine-mcp`	`MCP_TRANSPORT` unset	stdio, single-user, env-var credentials
`imagine-mcp --http`	`MCP_TRANSPORT=http` (or `TRANSPORT_MODE=http`)	HTTP daemon -- local `127.0.0.1` self-host, or multi-user remote when `PUBLIC_URL` + `MCP_DCR_SERVER_SECRET` are set

In stdio mode the server exits if none of the provider keys are set. The remote HTTP bind knobs (MCP_HOST, MCP_PORT) apply only when PUBLIC_URL is set; see Configuration.

Remote (HTTP mode)

An HTTP deployment serves clients that support remote HTTP MCP servers. It is OAuth-gated -- an unauthenticated request returns 401 with a WWW-Authenticate: Bearer challenge -- and credentials are provisioned through the browser setup form. Point an HTTP-capable MCP client at https://<your-host>/mcp and complete the OAuth flow to connect. To stand one up, see Deploy to Cloudflare.

Documentation

Full docs at mcp.n24q02m.com/servers/imagine-mcp/setup/:

Setup -- install methods for Claude Code, Codex, Gemini CLI, Cursor, Windsurf, mcp.json
Modes overview -- stdio / local-relay / remote-relay / remote-oauth
Multi-user setup -- per-JWT-sub credential model

Tools

Tool	Actions	Description
`understand`	--	Describe or reason over one or more image/video URLs. `media_urls: list[str]`, `prompt: str`, `provider`, `tier`, `max_tokens`.
`generate`	--	Generate an image or video from a text prompt. `media_type: image\|video`, optional `reference_image_url`, optional `job_id` (video poll), `aspect_ratio`, `duration_seconds`.
`config`	`setup_status`, `setup_skip`, `setup_reset`, `setup_complete`, `warmup`, `status`, `set`, `cache_clear` (`relay_status`/`relay_skip`/`relay_reset`/`relay_complete` honored as deprecated aliases)	Credential + runtime config: check credential state, set runtime knobs (log level, default provider, TTL), clear response cache.
`help`	--	Full Markdown documentation for `understand`, `generate`, or `config` topics.
`config__open_relay`	--	Framework-injected helper (mcp-core); opens the browser credential form.

Model choice is caller-driven (litellm provider/model passthrough or a *_MODELS env chain) -- see Model chains above.

Comparison

How imagine-mcp stacks up against direct competitors in each pillar:

Capability	imagine-mcp	EverArt MCP	fal.ai MCP	Replicate Flux MCP
Image/video understanding	Yes (describe / classify / reason over image + video URLs)	No	No	No
Image generation	Yes (text-to-image + image-to-image via `reference_image_url`)	Yes (single `generate_image`)	Yes (text/image-to-image, edit, inpaint)	Yes (single `generate_image`)
Video generation	Yes (text-to-video + image-to-video, async `job_id` poll)	No	Yes (text/image-to-video)	No
Multi-provider backends	Yes (Gemini / OpenAI / Grok, auto-fallback)	No (EverArt only)	No (fal.ai only)	No (Replicate Flux only)
Quality/cost tiers	Yes (`poor` cheap-fast vs `rich` high-quality per provider)	No	No	No
Self-hostable / open source	Yes (Apache-2.0, stdio + HTTP self-host)	Yes (MIT, archived)	Yes (MIT)	Yes (MIT, archived)

Security

SSRF + LFI prevention -- All media_urls and reference_image_url are validated at the dispatch boundary; only http:// and https:// schemes reach the providers. file://, ftp://, gopher://, and scheme-less URLs are rejected.
No credentials in errors -- Provider-side errors are sanitized before being returned.
Degraded start -- Missing credentials do not prevent the server from starting; affected actions surface actionable errors instead of crashing at boot.
Credential storage -- Credentials submitted through the browser credential form are stored encrypted via mcp-core (AES-GCM, machine-bound key) at ~/.imagine-mcp/config.json.

Workspace username (HTTP setup form)

The browser credential form has an optional workspace username field. Entering the same username always lands you in the same per-sub bucket, so your provider keys stay reachable across a re-authorization and across devices, instead of being tied to the one-off subject minted for each /authorize round-trip. Leaving it blank keeps the previous per-authorize behaviour.

Trust boundary: when the form is gated by a shared MCP_RELAY_PASSWORD, the username is a partition key, not a secret -- anyone who knows that password can type any username and reach that bucket. That is fine for a trusted group; an untrusted multi-tenant deployment needs a per-user secret or delegated OAuth instead.

One-time migration: existing users must re-enter their credentials once after this change. Nothing is deleted; credentials stored under the old random subject are simply no longer addressed.

Build from Source

git clone https://github.com/n24q02m/imagine-mcp.git
cd imagine-mcp
mise run setup      # or: uv sync --group dev
mise run dev        # run the server in stdio mode (add --http for the HTTP daemon)

Deploy to Cloudflare

Run your own imagine instance serverless on Cloudflare (Worker + Container + KV). Storage is KV-only -- the per-user credential vault lives in KV, and generation returns base64 only because the container filesystem is ephemeral (IMAGINE_OUTPUT_MODE=base64).

Prerequisites: a Cloudflare account on the Workers Paid plan -- required for Containers (the Cloudflare free tier does not include Containers) -- and the wrangler CLI.

git clone https://github.com/n24q02m/imagine-mcp && cd imagine-mcp
wrangler login
Create the KV namespace (imagine is KV-only -- no D1 or Vectorize), then paste the returned id into wrangler.jsonc (the <imagine-kv-namespace-id> placeholder):
```
wrangler kv namespace create imagine-kv
```

Push the container image to your Cloudflare managed registry (CF Containers cannot pull from external registries directly), then set <YOUR_ACCOUNT_ID> in wrangler.jsonc:

docker pull ghcr.io/n24q02m/imagine-mcp:beta
docker tag ghcr.io/n24q02m/imagine-mcp:beta imagine-mcp:beta
wrangler containers push imagine-mcp:beta   # prints registry.cloudflare.com/<ACCOUNT_ID>/imagine-mcp:beta

Point the remaining wrangler.jsonc placeholders at your own domain: <YOUR_PUBLIC_URL> (the vars.PUBLIC_URL, e.g. https://imagine.example.com) and <YOUR_WORKER_DOMAIN> (the routes custom-domain pattern, e.g. imagine.example.com).

Set secrets. CREDENTIAL_SECRET (stable JWT signing key + per-user vault key) and MCP_DCR_SERVER_SECRET (proof of an intentional multi-user deploy) are required; MCP_RELAY_PASSWORD gates the browser setup form's login. Provider keys are optional server defaults -- users normally paste their own through the setup form instead:

wrangler secret put CREDENTIAL_SECRET
wrangler secret put MCP_DCR_SERVER_SECRET
wrangler secret put MCP_RELAY_PASSWORD
wrangler secret put GEMINI_API_KEY       # optional provider default
wrangler secret put OPENAI_API_KEY       # optional provider default
wrangler secret put XAI_API_KEY          # optional provider default

wrangler deploy, then open your Worker domain and finish setup in the browser relay form.

The http container image already runs multi-user (MCP_TRANSPORT=http is baked into the image target). Storage maps to Cloudflare via MCP_STORAGE_BACKEND=cf-kv (encrypted credential vault) with IMAGINE_OUTPUT_MODE=base64, which forces base64 responses so no media path is written to the ephemeral container filesystem.

Trust Model

This plugin implements TC-Local (machine-bound, single trust principal). See mcp-core trust model for full classification.

Mode	Storage	Encryption	Who can read your data?
stdio (default)	`~/.imagine-mcp/config.json`	AES-GCM, machine-bound key	Only your OS user (file perm 0600)
HTTP self-host	Same as stdio	Same	Only you (admin = user)

Contributing

See CONTRIBUTING.md for the full development workflow, commit convention, and release process. Issues + Discussions welcome.

License

Apache-2.0 -- see LICENSE.

Available Tools

5 tools

configC

Destructive

ParametersJSON Schema

Name	Required	Description	Default
`key`	No
`value`	No
`action`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior3/5

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

Annotations indicate destructiveHint=true and readOnlyHint=false. The description lists actions including 'cache_clear' (destructive) and mentions deprecated aliases. No contradiction, but adds limited 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.

Conciseness2/5

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

The description is a single dense sentence with parenthetical lists, making it hard to parse. It combines multiple action categories and deprecated aliases without clear structure, reducing conciseness.

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?

With 3 parameters, no schema descriptions, and full behavioral burden on the description, it fails to cover return values, action semantics, or parameter usage. The output schema exists but is unmentioned.

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%, and the description does not explain parameters (key, value, action). The agent gets no meaning beyond the schema types and required fields.

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 handles server config and credential setup, listing specific actions. It distinguishes from sibling config__open_relay by noting that tool opens the credential form. However, the broad scope and dense list reduce clarity.

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 only offers one usage guideline: to use config__open_relay for opening the credential form. It does not explain when to use specific actions or how to choose among them, lacking guidance for the agent.

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

config__open_relayA

Get the relay configuration URL for imagine-mcp, opening it in the user's browser when possible. Returns the relay URL, whether the browser launched, and the current status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden. It transparently discloses the key side effect of launching the user's browser 'when possible' and lists what will be returned. It could add more about failure conditions or permissions, but for a zero-parameter tool the disclosure is solid.

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 wasted words. The primary action is front-loaded, the side effect is stated, and the return contents are summarized. Every sentence earns its place.

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 has no parameters and an output schema exists to document return values, the description provides all necessary context: what the tool does, what side effect it may have, and what it returns. Nothing essential is missing for an agent to select and invoke it correctly.

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?

The tool has zero parameters, so there is no parameter schema to elaborate on. The description appropriately focuses on the operation and its outputs, meeting the baseline for a parameterless tool.

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 states a specific verb ('Get'), a specific resource ('relay configuration URL for imagine-mcp'), and a clear side effect ('opening it in the user's browser when possible'). It is easy to distinguish from the generic sibling 'config' because it names the exact operation and output.

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 when to use the tool: when the agent needs the relay configuration URL and wants to attempt opening it in the browser. However, it does not explicitly mention when not to use it or compare it with the sibling 'config' tool, leaving some inference to the agent.

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

generateA

Generate an image or video from a text prompt. Video is async: first call returns job_id; call again with job_id to poll.

ParametersJSON Schema

Name	Required	Default
`tier`	No	poor
`model`	No
`job_id`	No
`prompt`	Yes
`provider`	No
`media_type`	Yes
`output_mode`	No	both
`aspect_ratio`	No	16:9
`duration_seconds`	No
`reference_image_url`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior4/5

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

Discloses async behavior for video, which is not captured by annotations; annotations already indicate write operation (readOnlyHint=false), consistent with generation.

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 with no filler; first covers purpose, second covers critical async flow.

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?

Despite having output schema, the description lacks information on most parameters, return values, and image generation behavior, making it incomplete for a complex tool.

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?

With 0% schema description coverage and 10 parameters, description only mentions 'text prompt' and 'job_id' implicitly, leaving all other parameters undocumented.

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 generates an image or video from a text prompt, distinguishing it from sibling tools like config or help.

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?

Explicitly mentions video is async and provides polling instructions, but does not specify when to use image vs video or provide alternatives.

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

helpA

Read-onlyIdempotent

Full documentation. Topics: understand | generate | config.

ParametersJSON Schema

Name	Required	Description	Default
`topic`	No		understand

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to repeat those. The description adds no significant behavioral detail beyond 'full documentation', but it also does not contradict the 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 extremely compact, front-loaded with the core purpose, and every word adds information. No filler or unnecessary repetition.

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 one-parameter help tool with strong annotations and an output schema, the description is mostly sufficient. The only notable gap is that the sibling config__open_relay is not reflected in the topic list, which could leave an agent unsure whether that tool has separate documentation.

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 description coverage is 0%, so the description's topic list provides the only meaningful guidance for the topic parameter. It enumerates valid values, which is valuable, though it does not explicitly mention the default value or explain each topic's content.

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 identifies this as a documentation/help tool and specifies the available topics: understand, generate, and config. It is unambiguous and distinguishable from the sibling tools, though it lacks an explicit action verb like 'returns' or 'displays'.

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 topic list implies that the tool should be used to retrieve documentation on those topics, but it never explicitly states when to prefer help over calling the sibling tools directly. Usage context is implied rather than stated.

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

understandA

Read-onlyIdempotent

Understand images and/or videos (multi-URL) with a prompt. Gemini supports mixed image+video in one call; OpenAI/Grok are image-only.

ParametersJSON Schema

Name	Required	Default
`tier`	No	poor
`model`	No
`prompt`	Yes
`provider`	No
`max_tokens`	No
`media_urls`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

Annotations already indicate readOnly, idempotent, non-destructive. Description adds provider-specific behavioral context (media type support), which is valuable beyond the 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, directly stating core function and provider distinction. No redundant information; front-loaded with the action.

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?

Output schema exists, so return values are covered. However, the description lacks parameter documentation, which is a significant gap given 6 parameters and 0% schema coverage. Overall adequate but incomplete.

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 description coverage is 0%, and the description does not explain any parameters (e.g., media_urls, prompt, tier, model). The agent must rely solely on parameter names, which is insufficient for correct usage.

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 understands images/videos with a prompt, and distinguishes provider capabilities (Gemini supports mixed media, others image-only). Verb+resource+scope is specific, and no sibling tool performs this function.

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?

Description provides context on provider differences (mixed vs. image-only), helping select provider. However, it does not explicitly state when to use this tool vs. alternatives or when not to use it.

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 tool updatev1.11.0Aug 29, 2026
- Addedhelp
1 tool updatev1.10.1Jul 18, 2026
- Removedhelp
5 tool updatesv1.8.1Jul 5, 2026
- First observedconfig
- First observedconfig__open_relay
- First observedgenerate
- First observedhelp
- First observedunderstand

Install Server

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

TDQS

A3.7/5.0

Scored 2026-08-30 00:10 across 5 tools

Disambiguation5/5

Each tool maps to a clearly distinct function: help, understanding media, generating media, configuration, and opening the relay credential form. The only closely related pair is config/config__open_relay, but the descriptions make their boundary explicit.

Naming Consistency4/5

Most tool names are simple lowercase imperatives (help, understand, generate), which is predictable and readable. config and config__open_relay break the bare-verb pattern slightly, and the double-underscore namespace is a minor deviation from an otherwise consistent style.

Tool Count5/5

Five tools is well-scoped for a focused multimodal generation/understanding server. The set covers core media operations, documentation, and configuration without redundant or excessive entries.

Completeness4/5

The essential workflows—understanding images/videos and generating images/videos—are covered, plus configuration and credential setup. The async video generation flow relies on calling generate again with a job_id rather than a dedicated status/cancel tool, which is a minor gap but not a blocker.

Maintenance

ActivityActive

ResponsivenessWithin a week

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

mcp-minimaxOAuth
io.github.AceDataCloud
MCP server for MiniMax H3 multimodal video generation
Image & Video Processing Multimedia Processing AI & Machine Learning
11
OpenAI Tools MCP Server B
ai.com.mcp
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Image & Video Processing Audio Processing Multimedia Processing
927
mcp-veoOAuth
io.github.AceDataCloud
MCP server for Google Veo AI video generation
Multimedia Processing Image & Video Processing Entertainment & Media
23
mcp-qwen-imageOAuth
io.github.AceDataCloud
MCP server for Qwen Image 3 AI image generation
AI & Machine Learning Image & Video Processing
1

Related MCP Servers

Grok MCP
Autonomous Agents Image & Video Processing Search
merterbak
A
license
A
quality
A
maintenance
Use XAI's latest api functionalities with Grok MCP. It supports image understanding and generation, live search, latest models and more.
Updated 13 days ago (2026-08-29 08:05 UTC)
22
51
MIT
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
universal-image-mcp
AI & Machine Learning Image & Video Processing
manu-mishra
A
license
A
quality
D
maintenance
MCP server for multi-provider AI image generation (AWS Bedrock, OpenAI, Google Gemini) enabling image generation, transformation, and editing through a unified interface.
Updated 6 months ago (2026-03-04 19:20 UTC)
4
1
MIT
Gemini Image & Video
AI & Machine Learning Image & Video Processing Multimedia Processing
collactivelabs
F
license
B
quality
D
maintenance
A production-ready MCP server that enables Claude and other LLMs to generate images and videos using Google's Gemini AI models (Gemini 2.0 Flash and Veo 2.0).
Updated a year ago (2025-10-24 05:57 UTC)
3
2
-

imagine-mcp

Table of contents

Features

Install

Smithery

Configuration

Provider keys

Model chains (optional)

Runtime knobs

CLI

Remote (HTTP mode)

Documentation

Tools

Comparison

Security

Workspace username (HTTP setup form)

Build from Source

Deploy to Cloudflare

Trust Model

Contributing

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers