Skip to main content
Glama
qmediat

ideogram-mcp

by qmediat
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Model pose variants

ideogram_model_pose_variants

Re-pose a fashion model in a source image using a plain-language pose or camera instruction, optionally with a reference pose, and save the generated variants.

Instructions

Re-pose the model of a fashion image by a plain-language pose or camera instruction (an optional pose reference asset). The source as a local file, a public https URL or an Ideogram asset. Results are saved to the output directory; long jobs come back as a generation_id for ideogram_generation; no price quote (the operation offers no dry run).

Input Schema

NameRequiredDescriptionDefault
seedNoRandom seed for a repeatable result
wait_sNoSeconds to wait for the result (0-50, default 45). The job is accepted first; if it is still running when the wait ends, the result is its generation_id for ideogram_generation (never resubmitted, never billed twice).
privateNoKeep the result out of Ideogram's public feed; true unless you set false (enterprise accounts are always private)
qualityNolow, medium or high: higher may improve detail and takes longer
num_imagesNoHow many outputs to make (each is billed)
instructionNoPlain-language direction: the pose or camera for a pose variant, the materials and construction for a render, the reconstruction guidance for a ghost mannequin
aspect_ratioNoOutput aspect ratio with a colon — 1:1, 3:4, 4:3, 16:9 or 9:16 where the operation lists them (colorways and material swap default to the photo's ratio, ghost mannequin and sketch to render to 1:1, pose variants to the nearest supported); magic prompt: the ratio to pin, or omitted for the model's pick
source_imageNoThe fashion image to edit, a local file or a public https URL; source_asset_identifier for an Ideogram asset
inline_imagesNotrue: each saved image is also returned as image content (base64; one over 3.75 MB, or past 10 MB in total, by path only), for a client without file access
pose_reference_asset_identifierNoAn Ideogram asset whose pose the model takes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.5.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations the description carries the full burden, and it delivers meaningful behavior: outputs are written to the output directory, long-running jobs return a generation_id rather than a result, and there is no dry run or price quote. It stops short of noting billing implications or permission requirements, but the async/retry model is clearly disclosed.

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?

Three sentences, front-loaded with the purpose before operational notes, with no filler. Slightly dense in the third sentence (output dir, generation_id handoff, no dry run packed together) but each clause earns its place.

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 ten-parameter generation tool with no annotations and no output schema, the description covers purpose, accepted source forms, output destination, and the long-job resumption path. It omits billing and authentication context, but nothing critical for correct invocation is missing.

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 ten parameters; the description only restates source formats (local file / https URL / Ideogram asset) and the pose reference, largely duplicating the schema. Baseline 3 is appropriate.

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?

States a specific verb and resource ('Re-pose the model of a fashion image') plus the governing input ('plain-language pose or camera instruction') and the optional pose reference. This distinguishes it cleanly from siblings like ideogram_ghost_mannequin, ideogram_material_swap and ideogram_precise_edit.

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

Usage Guidelines3/5

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

The narrow scope implies when to use it, and it notes the async handoff to ideogram_generation and the absence of a dry run / price quote. However it never explicitly contrasts with alternatives or states when NOT to use it, so the agent must infer selection.

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