Skip to main content
Glama
JensithAxboe

MeiGen AI Design MCP

by JensithAxboe
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

generate_product_detail_images

DestructiveIdempotent

Generate 1–6 coordinated ecommerce listing images from a real product photo, with optional selling points, logo, model photo, and extra angles to create marketplace-ready product pages.

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. This legacy local npm path requires an existing MeiGen key (MEIGEN_API_TOKEN or saved local configuration) and purchased credits. New connections use remote OAuth at https://www.meigen.ai/api/mcp. 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

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. auto chooses once for the entire set from the brief; omitted keeps 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. First observedv3.3.3

TDQS

A4.2/5.0
Behavior5/5

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

Goes far beyond the annotations: discloses that each module is a paid image, that no fixed completion time is guaranteed, that a batch is not atomic and an estimate is not a server-enforced cap, that a MeiGen key/purchased credits are required for this legacy path, and gives precise retry/recovery semantics (reuse requestId, preserve retryParameters, retry uploads at most once). This is exactly the cost/auth/partial-failure context the annotations cannot express.

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?

Purpose and requirements are front-loaded, but the body is a long run of process instructions with visible duplication — module selection from count is stated twice ('If only the count is specified, choose suitable modules' and 'when only a requested count is known, choose suitable modules unless the caller selected them'). Dense but not tight.

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

Completeness4/5

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

For a 16-parameter, paid, destructive, credential-gated tool with no output schema, the description covers prerequisites, budgeting, retry/recovery, partial-failure (non-atomic batches) and what is returned ('structured status, handles, errors and completed URLs'). Minor gaps remain around failure surfaces for individual modules, but overall it is sufficient to call the tool correctly.

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

Parameters3/5

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

Schema coverage is 94%, so the schema already documents nearly every parameter. The description adds a useful framing (one product photo plus a resolved count are the only hard requirements; logo, model photo, selling points and angles are optional) and clarifies the count↔modules relationship, but adds no new semantics for the remaining parameters.

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?

Opens with a specific verb+resource and scope: 'Create 1–6 coordinated ecommerce listing images', then immediately defines the module model (hero/detail/scene/material/usage/brand) that distinguishes it from generic siblings like generate_image or generate_marketing_poster. The required/optional input split is stated up front.

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

Usage Guidelines4/5

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

Explicit directives on when to act without asking ('An explicit user request or authorized upstream workflow establishes its count, quality and budget: do not reconfirm'), when to ask ('Ask only for missing required material or unresolved scope'), and which siblings to bypass ('skip unrequested prompt enhancement, preference loading and delegation'). It never cleanly contrasts the tool against generate_marketing_poster, so routing between image-generation siblings is still partly inferred.

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

Deploy Server

Other Tools