The MeiGen AI Image Generation MCP server turns LLMs into creative design assistants, supporting multi-provider image generation, prompt engineering, and a curated inspiration gallery.
Core Capabilities:
Generate Images: Create AI images using MeiGen Cloud, local ComfyUI, or any OpenAI-compatible API (e.g., Together AI, Fireworks AI). Supports prompts, reference images, aspect ratios, negative prompts, and quality settings.
Enhance Prompts: Transform simple ideas (e.g., "a cat in a garden") into detailed, professional prompts in realistic, anime, or illustration styles — free, no API key needed.
Search Gallery: Semantically search 1,500+ curated trending prompts with visual previews, filterable by category and sortable by rank, likes, views, or date.
Get Inspiration: Retrieve full prompt details and image URLs for any gallery entry to use as style references or direct generation input.
List Models: Browse available AI image generation models with pricing and capabilities across all configured providers.
Upload Reference Images: Compress and upload local images (JPEG, PNG, WebP, GIF) to temporary cloud storage as public URLs (expire in 24 hours) for use in generation.
Manage ComfyUI Workflows: List, view, import, modify, and delete ComfyUI workflow templates, including node parameters like steps, CFG, sampler, and dimensions.
Manage Preferences: Save and retrieve user defaults for style, aspect ratio, model, provider, style notes, and favorite prompts.
Parallel Generation: Generate multiple image variations or creative directions simultaneously using specialized sub-agents.
Slash Commands: Quick access via /meigen:gen, /meigen:find, /meigen:models, /meigen:ref, and /meigen:setup for streamlined workflows.
Includes an automation hook that automatically opens generated images in the macOS Preview application for immediate visual feedback and a more efficient design workflow.
Supports image generation by connecting to any OpenAI-compatible API endpoint, allowing users to leverage various external models and providers using a standardized interface.
An MCP server that turns any AI coding tool into a professional design assistant. 9 tools + a curated prompt library let it design logos, render product shots, animate stills into video, and orchestrate parallel batch variations. Works in Claude Code, Cursor, Codex, Windsurf, Roo Code, OpenClaw, Hermes Agent, and any MCP-compatible host — with the MeiGen platform, any OpenAI-compatible API, or your local ComfyUI as the backend.
Three backend modes: MeiGen cloud (DB-driven image & video model lineup — see list_models), OpenAI-compatible (bring your own key and endpoint), or local ComfyUI (offline, your GPU)
Built-in 1,446 curated prompt templates from nanobanana-trending-prompts plus style-aware prompt enhancement
Parallel batch generation via sub-agents to keep the main context clean — plus a standalone CLI for shell scripts and CI
Related MCP server: MCP Doubao Seedream 4.0
"Create 4 product display images for this perfume, one of which should feature a model."
Process — AI uploads the reference image, crafts 4 distinct prompts, then generates all 4 in parallel:
Result — 4 creative directions delivered in under 2 minutes:
Generated images:
MeiGen now hosts an official stateless remote MCP endpoint — no npm install, no local process, and its model lineup, pricing and time estimates stay in sync with production automatically (tool descriptions are rendered from the production database, refreshed hourly):
claude mcp add --transport http meigen https://www.meigen.ai/api/mcp \
--header "Authorization: Bearer meigen_sk_YOUR_TOKEN"Works with any Streamable-HTTP MCP client (2026-07-28 stateless protocol, with fallback for 2025-era clients). Read-only tools (search, model list, inspiration, generation status check) work without a token. The remote endpoint returns media URLs; if you want automatic local file saving, prompt-library offline search, ComfyUI bridging or the CLI, use the npm package below — both share the same account and credits.
# Add the plugin marketplace
/plugin marketplace add jau123/MeiGen-AI-Design-MCP
# Install
/plugin install meigen@meigen-marketplaceRestart Claude Code after installation (close and reopen, or open a new terminal tab).
Alternative marketplace — also available via wshobson/agents (30k+ stars):
/plugin marketplace add wshobson/agents
/plugin install meigen-ai-design@claude-code-workflowsThis marketplace doesn't bundle MCP server config. After installing, add to your project's
.mcp.json:{ "mcpServers": { "meigen": { "command": "npx", "args": ["-y", "meigen@1.4.0"] } } }
Free features work immediately after restart — try:
"Search for some creative inspiration"
To unlock image generation, run the setup wizard:
/meigen:setupThe wizard walks you through:
Choose a provider — local ComfyUI, MeiGen Cloud, or any OpenAI-compatible API (bring your own key & endpoint)
Enter credentials — ComfyUI URL, API token, or key
Done — restart Claude Code once more, then start generating
One command to set up MeiGen for any supported AI coding tool:
npx meigen init cursor # Cursor
npx meigen init vscode # VS Code / GitHub Copilot
npx meigen init windsurf # Windsurf
npx meigen init roo # Roo Code
npx meigen init claude # Claude Code (project-level)This writes the correct MCP config file with the right format and path for your tool. If a config file already exists, MeiGen is merged in without overwriting your other servers.
Install the full plugin from ClawHub (includes commands, skills, and MCP server):
openclaw bundles install clawhub:meigen-ai-designOr install only the skill (no commands/agents):
npx clawhub@latest install creative-toolkitFor shell scripts, CI pipelines, or anyone who wants AI image generation without an MCP host, MeiGen ships a one-shot gen command in the same npm package.
# Set your token once (get it at https://www.meigen.ai → Settings → API Keys)
export MEIGEN_API_TOKEN=meigen_sk_...
# Generate
npx meigen gen --prompt "a calico cat in a sunlit kitchen"
# With a specific model + aspect ratio
npx meigen gen -p "tech logo" -m midjourney-v8.1 -r 1:1
# With a reference image (local file auto-uploaded)
npx meigen gen -p "product hero shot" --ref ~/Desktop/bottle.jpg
# Submit only — print generationId without polling (good for CI)
npx meigen gen -p "..." --no-wait
# Machine-readable output (good for jq pipes)
npx meigen gen -p "..." --json | jq -r '.imageUrls[0]'The image is saved to ~/Pictures/meigen/ (override with MEIGEN_OUTPUT_DIR).
meigen gen --help lists all flags.
Add to your MCP config (e.g. .mcp.json, claude_desktop_config.json):
{
"mcpServers": {
"meigen": {
"command": "npx",
"args": ["-y", "meigen@1.4.0"],
"env": {
"MEIGEN_API_TOKEN": "meigen_sk_..."
}
}
}
}Free features (inspiration search, prompt enhancement, model listing) work without any API key.
Hermes Agent is a first-class MCP client — add MeiGen to ~/.hermes/config.yaml:
mcp_servers:
meigen:
command: "npx"
args: ["-y", "meigen@1.4.0"]
env:
MEIGEN_API_TOKEN: "meigen_sk_..."
timeout: 2700 # generate_video polls until the server reports a terminal state (long videos can run 15+ min) — default 120s is not enough
connect_timeout: 120 # first npx download can take a minuteThe
timeout: 2700andconnect_timeout: 120overrides are important — Hermes defaults (120s / 60s) are tuned for short-running tools and will time out on video generation or first-run npx downloads.
Tool | Free | Description |
| Yes | Search 1,446 curated trending prompts with visual previews (powered by nanobanana-trending-prompts) |
| Yes | Get full prompt, all images, and metadata for any gallery entry |
| Yes | Transform a brief idea into a professional image prompt |
| Yes | List available models across all configured providers |
| Yes | Manage ComfyUI workflow templates: list, view, import, modify, delete |
| Yes | Remember your preferred style, aspect ratio, model, and favorite prompts |
| Key | Generate an image — routes to the best available provider automatically. Local reference images are auto-compressed and uploaded. |
| Key | Generate video with a required model ID. Run |
| No | Check a generation by ID — follow-up after interrupted polling (the error message includes the ID). Retry instead of re-submitting to avoid double charges. |
Command | Description |
| Quick generate — skip conversation, go straight to image |
| Search 1,446 curated prompts for inspiration |
| Browse and switch AI models for this session |
| Interactive provider configuration wizard |
For shell scripts, CI pipelines, and terminal users who don't run an MCP host:
export MEIGEN_API_TOKEN=meigen_sk_...
npx meigen gen --prompt "a calico cat in a sunlit kitchen"
npx meigen gen -p "logo design" -m midjourney-v8.1 -r 1:1 --jsonSee Use as CLI (no MCP host required) for the full flag list.
MeiGen uses specialized sub-agents for efficient parallel execution:
Agent | Purpose |
| Executes |
| Writes multiple distinct prompts for batch generation (runs on Haiku for cost efficiency) |
| Deep gallery exploration without cluttering the main conversation (runs on Haiku) |
Switch creative modes with /output-style:
Creative Director — Art direction mode with visual storytelling, mood boards, and design thinking
Minimal — Just images and file paths, no commentary. Ideal for batch workflows
Config Check — Validates provider configuration on session start, guides setup if missing
Auto-Open — Generated images automatically open in Preview (macOS)
MeiGen MCP supports three image generation backends. Configure one or multiple — the system auto-selects the best available.
Run generation on your own GPU with full control over models, samplers, and workflow parameters. Import any ComfyUI API-format workflow — MeiGen auto-detects KSampler, CLIPTextEncode, EmptyLatentImage, and LoadImage nodes.
{
"comfyuiUrl": "http://localhost:8188",
"comfyuiDefaultWorkflow": "txt2img"
}Perfect for Flux, SDXL, or any model you run locally. Your images never leave your machine.
Cloud API with multiple models: GPT Image 2.0, Nanobanana 2, Seedream 5.0, and more. No GPU required.
Get your API token:
Sign in at meigen.ai
Click your avatar → Settings → API Keys
Create a new key (starts with meigen_sk_)
{ "meigenApiToken": "meigen_sk_..." }GPT Image 2.0 resolution & quality — the default model accepts two optional generate_image parameters:
resolution: e.g. "1K" / "2K" / "4K" — upgrade for posters, prints, wallpapers
quality: e.g. "low" / "medium" / "high" — use "low" for quick drafts and thumbnails
Seedance 2.0 video now renders native 4K — but only on the pro tier (mini/fast cap at 480p/720p); pass tier: "pro" for 1080p/4K output.
Each model exposes its own supported resolutions and quality tiers — run list_models to see what's available. For up-to-date pricing across all models, see meigen.ai/model-comparison.
Connect any image generation API that follows the OpenAI format — Together AI, Fireworks AI, DeepInfra, SiliconFlow, or your own endpoint. Just provide your key, base URL, and model name:
{
"openaiApiKey": "sk-...",
"openaiBaseUrl": "https://api.together.xyz/v1",
"openaiModel": "black-forest-labs/FLUX.1-schnell"
}All three providers support reference images. MeiGen and OpenAI-compatible APIs accept URLs directly; ComfyUI accepts both URLs and local file paths, injecting them into LoadImage nodes in your workflow.
/meigen:setupThe wizard walks you through provider selection, API key entry, and ComfyUI workflow import. You can also paste a curl command from your API provider's docs — it auto-extracts the key, URL, and model.
Configuration is stored at ~/.config/meigen/config.json. ComfyUI workflows are stored at ~/.config/meigen/workflows/.
Environment variables take priority over the config file.
Variable | Description |
| MeiGen platform token |
| Your API key (any OpenAI-compatible provider) |
| API base URL — change this to use Together AI, Fireworks AI, etc. |
| Model ID supported by your endpoint |
| ComfyUI server URL (default: |
| Override the local save directory for generated images (default: |
| Override the local save directory for generated videos (default: |
| Linux only — when |
| Linux only — same logic as |
MeiGen MCP respects your privacy. Here's what happens with your data:
ComfyUI (local) — All processing stays on your machine. No data is sent externally.
MeiGen Cloud — Prompts and reference images are sent to www.meigen.ai for generation. Generated images are stored temporarily on Cloudflare R2. See meigen.ai/privacy.
OpenAI-compatible — Prompts and reference images are sent to the configured API endpoint. See your provider's privacy policy.
Reference image upload — Images are compressed locally (max 2MB) and uploaded to Cloudflare R2 via gen.meigen.ai. Uploaded images expire automatically after 24 hours. No authentication required. ComfyUI users can skip uploading entirely by passing local file paths directly.
Gallery search — With a search query, the MeiGen API is queried (your query text is sent to www.meigen.ai); category browsing and offline fallback use bundled local data. Prompt enhancement runs locally with no external calls.
No telemetry, analytics, or tracking of any kind.
If you prefer to use your own S3/R2 bucket for reference image uploads, set the UPLOAD_GATEWAY_URL environment variable or uploadGatewayUrl in ~/.config/meigen/config.json to point to your own presign endpoint. The endpoint must implement:
POST /upload/presign
Content-Type: application/json
Request: { "filename": "photo.jpg", "contentType": "image/jpeg", "size": 123456 }
Response: { "success": true, "presignedUrl": "https://...", "publicUrl": "https://..." }The presignedUrl is used for a PUT upload, and publicUrl is the publicly accessible URL returned to the user.
MIT — free for personal and commercial use.
Manage ComfyUI workflow templates: list, view parameters, import from file, modify settings, or delete.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform on ComfyUI workflows | |
| name | No | Workflow name. Required for view/modify/delete. For import, used as the save name (defaults to filename). | |
| filePath | No | Path to a ComfyUI API-format workflow JSON file (for import action). | |
| nodeId | No | Node ID to modify (for modify action). Use "view" action first to see available node IDs. | |
| input | No | Input field name to modify (for modify action). E.g. "steps", "cfg", "sampler_name", "ckpt_name". | |
| value | No | New value as JSON (for modify action). Examples: "30", "\"euler\"", "7.5", "true". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive action (destructiveHint=true, readOnlyHint=false), and the description's action list is consistent with that. However, the description adds no extra behavioral details such as permanence of deletion, side effects of modification, or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary verb and lists all supported actions without fluff. It is appropriately sized for the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex multi-action interface with no output schema, and the description does not mention what actions return (e.g., whether view returns the workflow JSON or list returns names). While the param descriptions are thorough, the lack of output/return info leaves a gap for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with detailed descriptions for all six parameters, including the enum for action and examples for modify values. The description itself adds no parameter semantics beyond the schema, so baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool manages ComfyUI workflow templates and enumerates the five supported actions (list, view, import, modify, delete). This distinguishes it from sibling tools focused on generation or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for workflow template management but does not explicitly state when to use this tool over alternatives, nor does it mention any prerequisites or exclusions. However, the action list provides clear context for when each action is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transform a simple idea into a professional image generation prompt. Use when the user provides a brief description (e.g., "a cat in a garden") and needs a detailed, high-quality prompt. Combine with gallery inspiration for best results. Free, no API key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The simple prompt to enhance (e.g., "a cat in a garden") | |
| style | No | Target visual style: realistic (photorealistic), anime (2D/Japanese), illustration (concept art). Use "realistic" for general/photorealistic generation (GPT Image, Nanobanana, Seedream, Midjourney V8.1 in default mode, etc.). Use "anime" when the user wants anime/illustration output — V8.1 and most general-purpose models follow the prompt and benefit from explicit anime trigger words; the default "realistic" produces prompts poorly suited for stylized output. | realistic |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's mention of 'free, no API key needed' adds minor behavioral context. It does not detail rate limits or failure modes, but the tool's simplicity and annotation coverage make this acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a purpose: stating the transformation, providing a use case, and offering a tip. No wasted words, front-loaded with the main function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters and no output schema, the description covers the core functionality, usage context, and accessibility. It is sufficiently complete for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description's mention of 'simple idea' aligns with the prompt parameter, but adds no new information beyond the schema. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: transforming a simple idea into a professional image generation prompt. It provides a concrete example ('a cat in a garden') and implies its role as a prompt enhancer distinct from image generation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('when the user provides a brief description and needs a detailed, high-quality prompt') and suggests combining with gallery inspiration. It does not explicitly list when not to use or compare to siblings, 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.
Generate an image using AI. Supports MeiGen platform, local ComfyUI, or OpenAI-compatible APIs. Tip: get prompts from get_inspiration() or enhance_prompt(), and use gallery image URLs as referenceImages for style guidance. For Midjourney V8.1, an optional style reference can be passed by appending --sref <code> at the end of the prompt — only when the user provides a Midjourney style code (numeric or text). Do NOT pass URLs or local paths via --sref; for any image-based reference, use the referenceImages parameter instead.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The image generation prompt | |
| model | No | Model name. For OpenAI-compatible providers: any model ID your endpoint supports. For MeiGen: use model IDs from list_models (e.g. "gpt-image-2", "grok-image" = xAI Grok Imagine Quality, 1K/2K, supports image-to-image, "nanobanana-2", "seedream-4.5", "flux2-klein"). | |
| size | No | Image size for OpenAI-compatible providers: "1024x1024", "1536x1024", "auto". MeiGen/ComfyUI: use aspectRatio instead. | |
| aspectRatio | No | Aspect ratio for MeiGen provider. Use "auto" (recommended, default when omitted) to let MeiGen infer the best ratio from the prompt content. Explicit values: "1:1", "3:4", "4:3", "16:9", "9:16", "21:9", "2:3", "3:2", "4:5", "5:4", etc. (model-dependent). ComfyUI: use comfyui_workflow modify to adjust dimensions before generating. | |
| resolution | No | Resolution tier. MeiGen: "1K" / "2K" / "3K" / "4K" — each model supports a subset (list_models reports resolutions when applicable). OpenAI: not used (use size instead). | |
| quality | No | Image quality. MeiGen gpt-image-2: "low" / "medium" / "high". OpenAI-compatible providers also accept "high". | |
| referenceImages | No | Image references for style/content guidance. Accepts both public URLs (http/https) and local file paths. Local files are automatically compressed and uploaded when needed. For ComfyUI: local files are passed directly to the workflow (requires LoadImage node). Sources: gallery URLs from search_gallery/get_inspiration, URLs from previous generate_image results, or local file paths. | |
| provider | No | Which provider to use. Auto-detected from configuration if not specified. | |
| workflow | No | ComfyUI workflow name to use (from comfyui_workflow list). Uses default workflow if not specified. | |
| negativePrompt | No | Negative prompt for OpenAI-compatible providers. ComfyUI: use comfyui_workflow modify to set negative prompt in the workflow before generating. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a destructive operation (destructiveHint=true) and not read-only. The description elaborates on behaviors like automatic compression and upload of local files, and handling of reference images. It does not contradict annotations and adds useful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded with the main purpose. Every sentence provides useful information without redundancy. Tips and platform-specific notes are clearly separated and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, multiple providers, no output schema), the description covers the tool's behavior thoroughly, including provider-specific nuances and reference image handling. However, it does not describe the return format (e.g., whether the response includes URLs or base64), which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema (100% coverage), so the description's role is to add extra context. It does so effectively, e.g., explaining that referenceImages can come from gallery URLs, local paths, or previous results, and clarifying the use of size vs. aspectRatio across providers. This adds value beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate an image using AI' and specifies the supported platforms (MeiGen, ComfyUI, OpenAI-compatible APIs). It distinguishes this tool from sibling tools like generate_video and enhance_prompt, establishing a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides actionable guidance, such as obtaining prompts from get_inspiration() or enhance_prompt() and using gallery URLs as referenceImages. It also includes specific instructions for Midjourney V8.1 style codes. However, it does not explicitly state when NOT to use this tool or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a video using AI via MeiGen platform. Supports text-to-video, image-to-video (first/last frame), and reference-video continuation (Seedance 2.0 only — pass referenceVideo URL + referenceVideoDuration together, and prompt must explicitly say "extend / continue"). Available models include Seedance 2.0 (mini/fast/pro tiers, mini is the cheapest default, 4-15s), Happyhorse 1.0 (cost-effective, 3-15s), Veo 3.1 (fast/pro tiers, 4/6/8s, native audio), and Grok Video 1.5 (grok-video, xAI — IMAGE-TO-VIDEO ONLY, firstFrame required, native audio, 4-15s, 480p/720p). Pricing varies — seedance/happyhorse/grok are per-second, veo is per-generation by tier × duration. See https://www.meigen.ai/model-comparison for the current schedule. With a reference video (seedance only), billable seconds = max(reference_duration + duration, min_billable[duration]); total often higher than direct generation. Generation typically takes 1–5 minutes (veo at 4k can take up to ~8 min).
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The video generation prompt. Describe motion, scene, and style — not just the still image. | |
| model | Yes | Video model ID. Use list_models to see available video models. Common (as of writing): "seedance-2-0" (multi-tier general purpose), "happyhorse-1.0" (cost-effective i2v/t2v), "veo-3.1" (Google Veo with two tiers, 4/6/8s, native audio), "grok-video" (xAI Grok Imagine 1.5 — IMAGE-TO-VIDEO ONLY: firstFrame REQUIRED, pure text-to-video is rejected; native audio; 4-15s; 480p/720p). | |
| tier | No | Quality tier — only for models that support tiers. seedance-2-0 accepts "mini" (default, cheapest; 480p/720p, no reference video), "fast" (480p/720p), or "pro" (highest fidelity; native 1080p and 4K); veo-3.1 accepts "fast" (default) or "pro". Tiers may be added by the platform — call list_models to see what each model exposes. | |
| duration | No | Video duration in seconds. seedance-2-0 / happyhorse-1.0 currently accept ~3–15s (any integer in range). veo-3.1 accepts exactly 4, 6, or 8 (default 4) — other values will be rejected. Defaults to the model's default duration. Call list_models for the current allowed values per model. | |
| resolution | No | Output resolution. Common: "480p" / "720p" / "1080p" / "4k" (model-dependent; e.g. Seedance Pro adds 1080p and 4k, while Fast/Mini are 480p/720p only). Use list_models to see what each model supports. Higher resolutions cost more credits per second. | |
| aspectRatio | No | Aspect ratio: "16:9", "9:16", "1:1", "4:3", "3:4", "21:9", "auto", "adaptive" (model-dependent). Defaults to "auto" when omitted. | |
| firstFrame | No | First-frame image to control where the video starts. Accepts public URL or local file path (auto-uploaded). REQUIRED for grok-video (image-to-video only — backend rejects it without a firstFrame). For seedance/happyhorse/veo it is optional: with no first frame they do pure text-to-video. | |
| lastFrame | No | Optional last-frame image to also control where the video ends. Used by seedance-2-0 and veo-3.1; happyhorse-1.0 ignores this field. Accepts public URL or local file path. Requires firstFrame to also be provided — passing lastFrame alone is rejected. | |
| referenceVideo | No | Optional reference video URL for Seedance 2.0 "video continuation". Must be a publicly accessible HTTPS URL (typically a previous generation result `videoUrl`); local paths are not supported. Only seedance-2-0 accepts this — passing it with other models will fail. IMPORTANT — prompt requirement: to make the new clip semantically continue the reference, the `prompt` MUST explicitly say "extend" / "continue" (e.g. prefix with "Extend this video with the following plot:"). Without that, the model treats the video as visual reference only and the new clip may drift from a true continuation. Output behavior: the output is ONLY your `duration` seconds (4-15s) of new content — the reference video is NOT concatenated into the output. To get a single "original + new" clip the user must stitch them locally. Billing: credits are charged at the With-reference-video rate, with `billable_seconds = max(reference_duration + duration, min_billable[duration])`. Total cost is often higher than direct generation of the same output length. Always pass `referenceVideoDuration` alongside this field — omitting it causes underbilling and broken continuation behavior. | |
| referenceVideoDuration | No | Duration of the reference video in seconds (typically 2–15 — backend validates the current allowed range). REQUIRED whenever `referenceVideo` is set; if omitted the backend treats it as 0, leading to undercharged credits and misconfigured generation. Pass the actual duration of the clip at `referenceVideo`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description details generation time, billing logic for reference video, output behavior (only new content, not concatenated), and model-specific fidelity tiers. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized, front-loading the main purpose and then providing necessary details. Every sentence adds value, though it could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, minimal annotations), the description covers all modes, models, pricing, limitations, and expected output behavior comprehensively. It is complete for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet the description adds substantial extra context: required phrase for prompt with reference video, model-specific allowed durations, resolution restrictions per tier, and billing implications for referenceVideo. It significantly enriches the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool generates videos via AI on the MeiGen platform, supports multiple modes (text-to-video, image-to-video, reference-video continuation), and distinguishes itself from sibling tools like generate_image and list_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use different models, pricing structures, prerequisites for reference video (prompt must include 'extend'/'continue'), and model-specific constraints (e.g., grok-video is image-to-video only). It gives clear usage conditions without relying on siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full prompt and all image URLs for a gallery entry. Show the images to the user as visual examples. The prompt can be used directly with generate_image(), and image URLs can be passed as referenceImages for style transfer.
| Name | Required | Description | Default |
|---|---|---|---|
| imageId | Yes | Image/prompt ID from search_gallery results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the tool is safe. Description adds that it returns full prompt and image URLs and suggests showing images to users, which is helpful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences that front-load the main action and provide immediate value with downstream usage tips. No redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description fully explains what is returned and how to use it in conjunction with sibling tools. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the single parameter imageId. The tool description does not add further detail about the parameter, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full prompt and all image URLs for a gallery entry, distinguishing it from search_gallery (which lists entries) and generate_image (which creates images).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides direct guidance on using the prompt with generate_image() and image URLs as referenceImages for style transfer, and implies it should be used after selecting an entry from search_gallery. Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available AI image generation models and their capabilities. For up-to-date pricing, see https://www.meigen.ai/model-comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| activeOnly | No | Only show active models (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by noting that the tool lists capabilities and includes a link for pricing. However, it does not disclose other behavioral traits such as response format, caching, or rate limits, which would be beneficial for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: the first clearly states the purpose, and the second provides a useful external link for pricing. No extraneous information is present, and the key points are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional boolean parameter, readOnly annotation, no output schema), the description adequately covers the core functionality. It mentions capabilities and provides a pricing link, which complements the lack of output schema. However, some details about the returned data format could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage for the single parameter (activeOnly) with a clear description. The tool description does not add any additional meaning or context for this parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available AI image generation models and their capabilities, using a specific verb ('List') and resource ('models'). It effectively distinguishes itself from siblings like generate_image or enhance_prompt, which are action-oriented rather than retrieval-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., search_gallery or comfyui_workflow). There is no mention of exclusions or context for opting to use list_models over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read or update user preferences: default style, aspect ratio, model, style notes, and favorite prompts. Call with action "get" at conversation start to load preferences.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: "get" reads all preferences, "set" updates defaults/styleNotes, "add_favorite" saves a prompt, "remove_favorite" removes by index | |
| style | No | set: preferred default style (e.g. "realistic", "anime", "illustration") | |
| aspectRatio | No | set: preferred default aspect ratio. Use "auto" (recommended) to let MeiGen infer per-prompt, or pin a value like "16:9", "1:1", "9:16". | |
| model | No | set: preferred default model name | |
| provider | No | set: preferred default provider | |
| styleNotes | No | set: free-text style notes (e.g. "cinematic lighting, shallow DOF, brand colors #1A1A2E") | |
| prompt | No | add_favorite: the prompt text to save | |
| index | No | remove_favorite: 0-based index of the favorite to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint=false, implying mutation, and the description confirms 'Read or update'. No additional behavioral traits are disclosed (e.g., side effects, permissions, rate limits). The description adds minimal value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about return values for each action, especially since no output schema is provided. It mentions one usage scenario (get at conversation start) but not the semantics of other actions. Overall adequate but with noticeable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The tool description lists the preferences categories but does not add significant new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads or updates user preferences and lists specific preferences (style, aspect ratio, model, style notes, favorite prompts). It is a specific verb+resource combination that distinguishes it from sibling tools like generate_image or list_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises calling with action 'get' at conversation start to load preferences. However, it does not provide guidance on when to use 'set', 'add_favorite', or 'remove_favorite', nor does it mention when not to use this tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search AI image prompts with semantic understanding — finds visually and conceptually similar results, not just keyword matches. Results include image URLs — render them as markdown images () so users can visually browse and pick styles. Use when users need inspiration, want to explore styles, or say "generate an image" without a specific idea.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search keywords (e.g., "cyberpunk", "product photo", "portrait"). Supports semantic search — natural language descriptions work well. Leave empty to browse by category or get random picks. | |
| category | No | Filter by category. Available: Photography, Illustration & 3D, Product & Brand, Food & Drink, Poster Design, UI & Graphic | |
| limit | No | Number of results (1-20, default 5) | |
| offset | No | Pagination offset | |
| sortBy | No | Sort order when browsing without search query (default: rank) | rank |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds behavioral context by mentioning that results include image URLs and should be rendered as markdown images, which helps the agent understand the expected interaction. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at three sentences, all of which are meaningful. The main purpose is front-loaded, followed by usage guidance and display instructions. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description covers the main functionality, when to use, how to query (including empty query behavior), and how to display results. It lacks explicit pagination details, but given the schema's parameter descriptions, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing usage tips for the query parameter (e.g., natural language works well, leave empty to browse) and implies category usage. This exceeds the bare schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs semantic search for AI image prompts, distinguishing itself from keyword searches. It also specifies that results include image URLs and how to render them, making the purpose very clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: for inspiration, exploring styles, or when users say 'generate an image' without a specific idea. While it doesn't explicitly list alternatives, the context and sibling tool names allow the agent to infer 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.3.3generate_image1 field changedInput schema / properties / model / descriptionPrevious value: -"Model name. For OpenAI-compatible providers: any model ID your endpoint supports. For MeiGen: use model IDs from list_models."New value: +"Model name. For OpenAI-compatible providers: any model ID your endpoint supports. For MeiGen: use model IDs from list_models (e.g. \"gpt-image-2\", \"grok-image\" = xAI Grok Imagine Quality, 1K/2K, supports image-to-image, \"nanobanana-2\", \"seedream-4.5\", \"flux2-klein\")."generate_video4 fields changedInput schema / properties / firstFrame / descriptionPrevious value: -"Optional first-frame image to control where the video starts. Accepts public URL or local file path (auto-uploaded). Highly recommended for image-to-video; with no first frame the model does pure text-to-video."New value: +"First-frame image to control where the video starts. Accepts public URL or local file path (auto-uploaded). REQUIRED for grok-video (image-to-video only — backend rejects it without a firstFrame). For seedance/happyhorse/veo it is optional: with no first frame they do pure text-to-video."Input schema / properties / model / descriptionPrevious value: -"Video model ID. Use list_models to see available video models. Common (as of writing): \"seedance-2-0\" (multi-tier general purpose), \"happyhorse-1.0\" (cost-effective i2v/t2v), \"veo-3.1\" (Google Veo with two tiers, 4/6/8s, native audio)."New value: +"Video model ID. Use list_models to see available video models. Common (as of writing): \"seedance-2-0\" (multi-tier general purpose), \"happyhorse-1.0\" (cost-effective i2v/t2v), \"veo-3.1\" (Google Veo with two tiers, 4/6/8s, native audio), \"grok-video\" (xAI Grok Imagine 1.5 — IMAGE-TO-VIDEO ONLY: firstFrame REQUIRED, pure text-to-video is rejected; native audio; 4-15s; 480p/720p)."Input schema / properties / resolution / descriptionPrevious value: -"Output resolution. Common: \"480p\" / \"720p\" / \"1080p\" (model-dependent). Use list_models to see what each model supports. Higher resolutions cost more credits per second."New value: +"Output resolution. Common: \"480p\" / \"720p\" / \"1080p\" / \"4k\" (model-dependent; e.g. Seedance Pro adds 1080p and 4k, while Fast/Mini are 480p/720p only). Use list_models to see what each model supports. Higher resolutions cost more credits per second."Input schema / properties / tier / descriptionPrevious value: -"Quality tier — only for models that support tiers. seedance-2-0 and veo-3.1 currently accept \"fast\" (default, cheaper) or \"pro\" (higher fidelity). Tiers may be added by the platform — call list_models to see what each model exposes."New value: +"Quality tier — only for models that support tiers. seedance-2-0 accepts \"mini\" (default, cheapest; 480p/720p, no reference video), \"fast\" (480p/720p), or \"pro\" (highest fidelity; native 1080p and 4K); veo-3.1 accepts \"fast\" (default) or \"pro\". Tiers may be added by the platform — call list_models to see what each model exposes."v1.3.1comfyui_workflowenhance_promptgenerate_imagegenerate_videoget_inspirationlist_modelsmanage_preferencessearch_galleryScored across 8 tools
Most tools have distinct purposes (prompt enhancement, gallery search, model listing, generation). Some ambiguity exists between search_gallery and get_inspiration — both relate to gallery content, but search_gallery is for browsing while get_inspiration retrieves specific details. Similarly, generate_image and generate_video are clearly separated by output type.
The naming pattern is mostly verb_noun (enhance_prompt, search_gallery, list_models, get_inspiration, manage_preferences, generate_image, generate_video). However, comfyui_workflow breaks the pattern by being a noun phrase that implies a category rather than a specific action. This is a minor deviation but the rest is consistent.
8 tools is within the ideal range and covers the core functionality of image generation, prompt enhancement, gallery exploration, and preferences. It's slightly heavy given that comfyui_workflow and manage_preferences are auxiliary, but the count is appropriate for the server's scope.
The server covers the core workflow: get inspiration, enhance prompt, generate image/video. However, there is no tool to manage generated images (e.g., list, download, delete), and no tool to manage user projects. Additionally, while manage_preferences handles preferences, it doesn't cover user account management. This creates notable gaps for a complete lifecycle.
LLM chat, text tools, image generation, editing, batch image jobs, and asynchronous video generation
Generate images, video & speech with Nano Banana, Veo, Omni and Gemini TTS. Pay as you go.
Remote MCP for RunComfy: ComfyUI deployments, hosted models, LoRA training. 31 tools.
Self-hosted AI prompt library: prompts, collections, tags, teams, chains. 29 MCP tools for agents.
