Skip to main content
Glama
Sign In
JensithAxboe

MeiGen AI Design MCP

by JensithAxboe
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

generate_ai_background

DestructiveIdempotent

Create a product photo with a new background—white, AI-selected, or custom—while preserving the product.

Instructions

Create one product photo with a new background. Required: one actual product photo. White mode produces a fixed white background; smart chooses a scene; custom needs a background description, inferred from the request when present (e.g. a beach). Background references are not required. Use remove_background for transparent PNG cutouts. 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
modeNowhite=fixed white-background output; smart=AI chooses a suitable scene (default); custom=customPrompt required.
ratioNoSupported output ratio from list_skills for this Skill; omit for its default. Smart/custom only; auto matches source proportions. Ignored in white mode.
qualityNoSmart/custom only: fast=1K default, hd=2K; ignored in white mode.
requestIdYesGenerate a new UUID for a new paid request; reuse the SAME requestId and inputs on retry. Use check_skill after interruptions.
customPromptNoRequired in custom mode: describe the desired background and lighting.
productImageYesRequired product photo: preserve the product while replacing its surroundings. Do not pre-remove its background. 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.3.3

TDQS

A4.1/5.0
Behavior5/5

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

Annotations cover the safety profile (destructive, idempotent, open-world, non-read-only), and the description adds substantial non-obvious behavior: required MeiGen key and purchased credits, automatic upload of local/HTTPS inputs, non-atomic batches, in-flight charge accounting, single retry on transient upload failure, and requestId persistence rules. This is well beyond what the annotations convey.

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

Conciseness2/5

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

The core purpose is front-loaded, but the body runs to roughly fifteen sentences, much of it generic agent policy (skip prompt enhancement, skip delegation, don't reconfirm scope, explain problems in the user's language) rather than tool-specific behavior. Those lines inflate the definition without helping an agent invoke this tool correctly.

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 paid, destructive, credential-gated tool with no output schema, the description does cover auth, upload handling, retry/recovery precedence, and the shape of what is returned (status, handles, errors, completed URLs). Only the polling flow via check_generation is left implicit.

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 description coverage is 100%, so the schema already documents all six parameters, including mode, ratio, quality, customPrompt and productImage constraints. The description restates mode semantics and adds minor framing ('background references are not required', 'inferred from the request'), which is marginal over the schema baseline.

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?

First sentence gives a specific verb and resource: 'Create one product photo with a new background.' It further differentiates from the sibling remove_background by naming it and stating its distinct purpose (transparent PNG cutouts).

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?

It explicitly explains how to pick among white/smart/custom modes and when to prefer remove_background instead, plus the precondition of a legit product photo. It does not, however, distinguish itself from other generation siblings like generate_image or generate_product_detail_images, so routing is only partially resolved.

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