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 provide destructiveHint: true, so the description adds minimal behavioral context. It mentions delete action, which aligns, but no additional traits like persistence or side effects are disclosed.
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?
Single sentence with front-loaded actions. 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?
Given 6 parameters, 1 required, no output schema, and rich sibling context, the description covers the gist well. Could mention return values for list/view, but overall adequate.
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 descriptions. The description adds marginal value, e.g., default save name for import. Baseline 3 is appropriate as the schema carries most semantic weight.
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 it manages ComfyUI workflow templates and lists specific actions (list, view, import, modify, delete). This verb+resource combination distinguishes it from siblings which are about prompt/image generation, models, preferences, etc.
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 implicitly identifies this as the sole tool for workflow management, but lacks explicit guidance on when to use vs alternatives or when not to use. It does provide parameter dependencies in schema descriptions, e.g., which actions require which parameters.
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 declare readOnlyHint=true, and the description adds 'Free, no API key needed,' providing cost and authentication transparency beyond what annotations offer. No behavioral contradictions are present.
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 extremely concise: two sentences that convey purpose, usage, and key traits. Every sentence earns its place without unnecessary fluff.
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 tool with two parameters, no output schema, and read-only behavior, the description covers purpose, usage, transparency, and parameter guidance. Minor missing detail: the output format of the enhanced prompt is not described, but it is not essential given the tool's simplicity.
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?
Although schema coverage is 100%, the description (especially the detailed guidance on the 'style' enum) adds significant contextual meaning, explaining when to use each style and how it affects prompt generation. This goes beyond what the schema alone provides.
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 function: 'Transform a simple idea into a professional image generation prompt.' This distinguishes it from siblings like generate_image (which generates images) and get_inspiration (which provides gallery ideas).
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 says 'Use when the user provides a brief description... and needs a detailed, high-quality prompt' and suggests combining with gallery inspiration. However, it does not mention when not to use or explicitly name sibling alternatives, leaving some ambiguity.
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 already mark readOnlyHint=true; description adds value by detailing returned content (prompt, image URLs) and suggesting usage, without contradicting 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 sentences, each adds value: purpose, usage, integration. No fluff, 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 simple tool with one parameter and no output schema, description fully explains what the tool returns and how to use it, making it self-contained.
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 covers 100% of parameter; description repeats schema description but adds no new semantic detail about the parameter itself.
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 it retrieves full prompt and all image URLs for a gallery entry, and distinguishes from siblings by specifying how output integrates with generate_image() and style transfer.
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?
Implied usage after search_gallery; provides concrete guidance on how to use output (show images, use prompt and referenceImages). No 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?
Annotations already declare readOnlyHint=true. The description adds the pricing URL and mentions capabilities but does not elaborate on behavioral traits beyond the read-only nature. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. Front-loaded with purpose, then a helpful link. No wasted 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?
Given the simple tool (one optional param, read-only, no output schema), the description covers purpose and directs to pricing. It is complete for an agent to understand the tool's function.
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 one parameter (activeOnly) already described. The description does not add further meaning beyond what the schema provides, so 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 'List available AI image generation models and their capabilities,' which is a specific verb-resource pair. It distinguishes from siblings like generate_image, generate_video, comfyui_workflow, etc., which are generation or enhancement 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 implies usage for browsing models before generation, but it doesn't explicitly state when to use or not use it versus alternatives, nor does it provide exclusions. However, the purpose is straightforward and context is clear.
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.
Each tool targets a distinct task: workflow management, prompt enhancement, image generation, video generation, gallery inspiration, model listing, preferences, and gallery search. No significant overlap.
All tool names follow a consistent verb_noun pattern (e.g., enhance_prompt, generate_image, search_gallery), making it predictable for an agent.
With 8 tools, the set covers the core image generation workflow without being overwhelming or sparse. Each tool serves a clear purpose.
Major operations are covered: generation, prompt enhancement, gallery search, workflow management, and preferences. Minor gaps exist (e.g., no explicit image editing or history), but the surface is largely complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate images, video & speech with Nano Banana, Veo, Omni and Gemini TTS. Pay as you go.
Generate AI images and videos (Flux, Nano Banana, Kling, Veo, 48+ models), refunds on failure.
Self-hosted AI prompt library: prompts, collections, tags, teams, chains. 29 MCP tools for agents.
Create images and videos from prompts, with options for image mixing, reference images, and start/…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jau123/MeiGen-AI-Design-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
