apparelhub-mcp

Official

Overview Schema Source Related Servers Discussions Admin

generate_image

Create a design image from a prompt for custom apparel and products, with optional style, size, and themed concepts; use process_transparency when you need a transparent background.

Instructions

Generate a design image (split primitive of design_apparel). Returns the raw generated image; follow with process_transparency for apparel that needs a transparent background. Rate-limit errors are classified (model_rate_limited = one model's provider vs platform_rate_limited = this key's ApparelHub throttle vs request_not_sent = the call never reached ApparelHub), and fallback_trail shows any model substitutions. When the platform has advice on the prompt it is returned as prompt_improvement (advisory, never applied for you). If its issues include "brand_brief", the prompt describes a whole brand, collection or storefront rather than one design, and improved_prompt is the single strongest design EXTRACTED from it: either generate that one design, or keep the brief and call again with concepts (4 is a good default) to get a themed set from one generation. With concepts > 1 this still returns ONE image; the other designs from the same generation are saved to the workspace and read with get_design_collection(image_uuid).

[#e5867b]

Input Schema

Name	Required	Description
`size`	No	Output shape. 1024x1024 = square; 1024x1792 = tall/portrait (phone cases, posters, banners); 1792x1024 = wide/landscape (mugs, laptop sleeves, wide banners). Pick to match the product's print area — full-bleed goods like phone cases want a tall design that fills the whole area, or the mockup pads/crops it. To re-shape an EXISTING design without spending another generation, use fit_aspect instead.
`style`	No
`prompt`	Yes
`source`	No	Explicit model name, or omit to auto-pick (Nano Banana; OpenAI for abstract).
`concepts`	No	How many distinct design concepts to ask ONE generation for. Leave unset (1) for ordinary work. Raise it when the prompt is a whole brand or collection brief you want to keep (prompt_improvement reports "brand_brief"): the model is asked for a themed set instead of one image. Capped at 7 (ask for more and you get 7); the model may return fewer. Only sources whose supports_collection is true can do it (Nano Banana today); on any other source, including one the fallback ladder moved to, it is silently reduced to 1 and this tool says so in a warning. Costs ONE image generation either way, because it is one model call; the extra designs cost nothing. Each extra design carries the product name and retail description the model wrote for it.
`workspace`	No
`no_fallback`	No	Disable the model-fallback ladder. By default a rate-limited/transient model transparently retries with a different model (see fallback_trail); set true to fail on the chosen source alone.
`augment_prompt_for_transparency`	No	Add the solid-green-background hint so the background can be keyed out (default true).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.16.2Oct 20, 2026

addedInput schema / properties / concepts

Added value: +{
+  "description": "How many distinct design concepts to ask ONE generation for. Leave unset (1) for ordinary work. Raise it when the prompt is a whole brand or collection brief you want to keep (prompt_improvement reports \"brand_brief\"): the model is asked for a themed set instead of one image. Capped at 7 (ask for more and you get 7); the model may return fewer. Only sources whose supports_collection is true can do it (Nano Banana today); on any other source, including one the fallback ladder moved to, it is silently reduced to 1 and this tool says so in a warning. Costs ONE image generation either way, because it is one model call; the extra designs cost nothing. Each extra design carries the product name and retail description the model wrote for it.",
+  "maximum": 9007199254740991,
+  "minimum": 1,
+  "type": "integer"
+}

First observedv0.15.2Sep 29, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only carry openWorldHint, so the description carries the behavioral burden and does so richly: the three-way rate-limit error taxonomy, fallback_trail substitutions, advisory-only prompt_improvement, the silent reduction of concepts to 1 on unsupported sources, and the fact that concepts>1 still returns exactly one image while saving the rest to the workspace.

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

Conciseness4/5

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

One dense, front-loaded paragraph where nearly every sentence carries operational information the schema does not. It is long but earns most of its length; the trailing stray token '[#e5867b]' is noise and the parenthetical nesting makes it harder to scan than it needs to be.

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?

With no output schema, the description correctly covers the return surface (raw image, fallback_trail, prompt_improvement, warning on reduced concepts) and the chaining path. Gaps remain on the non-enum parameters (style, workspace) and there is no mention of credits/cost beyond the footnote on concepts, but nothing that would cause an incorrect call.

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 63%, so the baseline is 3. The description meaningfully extends `concepts` (brand_brief extraction, capped at 7, silently reduced to 1, costs one generation) but adds nothing for size, style, source, workspace, no_fallback or augment_prompt_for_transparency, which are left entirely to the schema and its enum that is documented only for size.

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 precise verb+resource ('Generate a design image') and immediately positions itself relative to a sibling by calling itself the 'split primitive of design_apparel'. An agent can distinguish this from design_apparel, iterate_design and generate_listing_image without opening any schema.

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?

Explicit routing: follow with process_transparency for transparent-background apparel, keep the brief and raise concepts when prompt_improvement reports 'brand_brief', and read the overflow designs via get_design_collection. It states both when to use this tool and which sibling to chain next.

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

Deploy Server

generate_image

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools