Skip to main content
Glama
qmediat

ideogram-mcp

by qmediat
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Material swap

ideogram_material_swap

Replace the material of masked product photo regions with reference image color, texture, and pattern, up to four mask-material pairs.

Instructions

Apply the material of reference images — colour, texture, pattern scale, orientation — to the masked regions of a product photo (up to 4 masks and materials, paired by position). Files, public https URLs or Ideogram assets. Results are saved to the output directory; long jobs come back as a generation_id for ideogram_generation; ideogram_quote prices a call first.

Input Schema

NameRequiredDescriptionDefault
imageNoThe source photo or ad to work on: a local image file or a public https URL (image_asset_identifier for an Ideogram asset)
masksNoLocal mask files (or public https URLs) marking the regions to change, paired by position (at most 4, the product photo's pixel size)
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
materialsNoLocal material reference images (or public https URLs) whose colour, texture, pattern scale and orientation are applied, paired by position with masks (at most 4)
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
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
image_asset_identifierNoAn Ideogram asset (an upload or an earlier result) instead of a local image
mask_asset_identifiersNoIdeogram assets as the masks, paired by position (at most 4)
material_asset_identifiersNoIdeogram assets as the material references, paired by position (at most 4)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.5.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description does real work: it discloses the async contract (job accepted first, generation_id returned if still running, never resubmitted or billed twice), where results land (output directory), asset-vs-file inputs, and the positional pairing of masks to materials. It doesn't cover permissions or account requirements, but the operational profile is well conveyed.

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

Conciseness5/5

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

Three tight sentences, front-loaded with the core action and its field-level detail, then the input mediums, then the async/quoting follow-ups. No filler or repetition.

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 an 11-parameter, no-output-schema, no-annotation tool, the description covers mechanism, pairing limits, input mediums, result location, and async/quoting handoffs — enough to invoke it correctly. It stops short of stating prerequisites or how mask/material counts must align on failure. Minor gaps only.

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 baseline is 3, and the description largely restates what the schema already says (files/URLs/assets, pairing by position, max 4). It adds no extra format detail on wait_s, quality, or inline_images beyond the schema text.

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 precise verb and resource — applying reference-image material (colour, texture, pattern scale, orientation) to masked regions of a product photo — plus scope limits (up to 4 masks/materials, paired by position). This is clearly distinguishable from sibling edits like ideogram_colorways or ideogram_replace_background.

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?

It points to the surrounding workflow (long jobs return a generation_id for ideogram_generation, ideogram_quote prices first) which implies when to poll and when to price, but it never states when to pick this tool over an adjacent edit tool such as colorways or remix. Usage is implied rather than contrasted.

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