Skip to main content
Glama
jau123

MeiGen AI Image Generation MCP

by jau123

generate_product_detail_images

Create 1–6 coordinated ecommerce listing images from one product photo. Select modules for hero shots, close-ups, lifestyle scenes, materials, usage, or brand story.

Instructions

Create 1–6 coordinated ecommerce listing images. Required: one actual product photo and a resolved image count. Product name, verified selling points, logo, model photo and extra angles are optional. Each module creates one paid image. If only the count is specified, choose suitable modules; MCP calls must explicitly select modules to match that count. Requires a MeiGen API key configured for this local npm server (MEIGEN_API_TOKEN or saved local configuration), and purchased credits only. Local files and external public HTTPS URLs are uploaded automatically. Use the dedicated skill directly; skip unrequested prompt enhancement, preference loading and delegation. Preserve caller-supplied inputs. Infer omitted optional settings from the request and defaults; when only a requested count is known, choose suitable modules unless the caller selected them. Ask only for missing required material or unresolved scope. An explicit user request or authorized upstream workflow establishes its count, quality and budget: do not reconfirm that scope or add paid images. The caller persists a requestId for each logical step; never ask an end user for technical IDs. Use live list_skills prices and account for in-flight charges when planning within a budget; a batch is not atomic and an estimate is not a server-enforced spending cap. Recovery actions take precedence over generic retry advice: check an interrupted submission, preserve exact retryParameters and do not create a new ID or replace failed modules automatically. Retry a temporary upload at most once after the suggested wait. Return structured status, handles, errors and completed URLs to the caller; it owns progress, previews, downloads and final presentation. If interacting directly with the user, explain the problem and a concrete next step in their language. Describe image details only after actual inspection.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
logoNoOptional exact brand logo to reproduce accurately. An accessible absolute local path (Windows drive/UNC, POSIX, ~/, or file://) or public direct HTTPS image URL without credentials, fragments or custom ports. Relative paths are ambiguous and rejected. Files are fully decoded, metadata removed, transparency preserved; GIF uses the first frame. Never invent attachment paths or URLs.
modulesYesRequired selection; one paid image each: hero=main shot, detail=close-up, scene=lifestyle, material=texture/craft, usage=how to use, brand=brand story. Set [] for custom modules only; otherwise select modules explicitly. Match the requested count.
qualityNolow=Fast (default); medium=Pro. These select rendering quality, not output resolution. Read list_skills for current output specifications and purchased-credit prices; no fixed completion time is guaranteed.
autoCopyNoDefault true: draft copy from the supplied product brief. False: preserve supplied wording, subject to the selected-language translation.
languageNoCopy language, e.g. auto, en, zh; see list_skills for supported values
platformNoMarketplace preset from list_skills; default amazon.
uiLocaleNoOptional UI locale fallback; language controls the text inside images.
requestIdYesGenerate a new UUID for a new paid request; reuse the SAME requestId and inputs on retry. Use check_skill after interruptions.
modelImageNoOptional person/model reference for hero and scene modules: show that person wearing or using the product. Not an image-generation model identifier. An accessible absolute local path (Windows drive/UNC, POSIX, ~/, or file://) or public direct HTTPS image URL without credentials, fragments or custom ports. Relative paths are ambiguous and rejected. Files are fully decoded, metadata removed, transparency preserved; GIF uses the first frame. Never invent attachment paths or URLs.
aspectRatioNoSupported output ratio from list_skills; default 4:5.
productNameNoOptional supplied product name; do not invent a brand or model.
productImageYesRequired main product photo: preserve the actual shape, color, packaging and readable labels. An accessible absolute local path (Windows drive/UNC, POSIX, ~/, or file://) or public direct HTTPS image URL without credentials, fragments or custom ports. Relative paths are ambiguous and rejected. Files are fully decoded, metadata removed, transparency preserved; GIF uses the first frame. Never invent attachment paths or URLs.
customModulesNo
sellingPointsNoOptional verified benefits or specifications from the caller; do not invent product claims.
extraRequirementsNoOptional additional copy, layout or product presentation requirements from the caller; preserve factual constraints.
extraProductImagesNoOptional extra product angles or detail photos, up to two; these supplement the main productImage.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.1

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so extensively. It discloses that each module creates one paid image, that batches are not atomic, that estimates are not spending caps, that uploads are automatic, that retries should preserve retryParameters, and that recovery actions take precedence over generic retry advice. It also explains the requestId reuse semantics and that image details should only be described after actual inspection.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is information-dense and front-loaded with the core purpose, but it is quite long and covers many operational details that could arguably live in a separate workflow document. Every sentence does add some value, but the density makes it harder to parse quickly. It is structured as a block of prose rather than scannable sections, which hurts usability for an agent.

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

Completeness5/5

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

For a complex paid-image-generation tool with 16 parameters, no annotations, and no output schema, the description is remarkably complete. It covers required inputs, optional inputs, pricing/credit behavior, retry semantics, error recovery, caller responsibilities, and user interaction guidelines. The only minor gap is that it doesn't describe the exact return structure, but it explicitly says it returns 'structured status, handles, errors and completed URLs,' which is sufficient given no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 94%, so the schema already documents most parameters well. The description adds meaningful context beyond the schema: it explains the relationship between modules and count ('MCP calls must explicitly select modules to match that count'), clarifies that quality selects rendering quality not resolution, and emphasizes that productName and sellingPoints must not be invented. It doesn't add per-parameter syntax details, but the schema already covers those.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Create 1–6 coordinated ecommerce listing images.' It clearly distinguishes this tool from siblings like generate_marketing_poster or generate_ai_background by focusing on coordinated listing images with modules. It also names the dedicated skill and explicitly says to skip delegation, which further differentiates it.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: 'Use the dedicated skill directly; skip unrequested prompt enhancement, preference loading and delegation.' It also states when to ask the user ('Ask only for missing required material or unresolved scope') and when not to reconfirm scope. It references list_skills for prices and check_skill for interruptions, providing clear alternatives and recovery paths.

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