devkindhq Ideogram Prompting
Ideogram 4 was trained on structured JSON captions, not plain text — a plain-text prompt gets expanded into that structure by a "magic prompt" step before it ever reaches the model. That gives you two ways to prompt, and picking the right one depends on how much control the user actually wants.
Two modes
Loose / exploratory — write a natural-language prompt and let the model's own interpretation (magic prompt) fill in color, lighting, composition. Good for quick ideas, loose briefs, or when the user wants to be surprised. Just call mcp__ideogram__generate_image with a prompt string; don't over-specify.
Precise — when the user names an exact palette, a specific composition, or text that must render legibly, write the prompt as a structured caption instead of a vague adjective list. See references/json-caption-schema.md for the full schema (aesthetics/lighting/medium/color_palette, bounding-box elements, etc) — either follow its field structure in prose form, or paste the JSON itself into the prompt string as an experiment. Note: the connected generate_image tool has no explicit magic_prompt toggle (unlike edit_image, which does), so JSON-in-prompt isn't a guaranteed bypass the way it is in Ideogram's raw API — compare against a well-written prose version and keep whichever renders closer to what was asked for.
Either way, the highest-leverage lever is color_palette: up to 16 uppercase #RRGGBB hex codes steer the image's dominant colors directly, and up to 5 per element for per-subject control. If the user cares about exact colors, always name them as hex, not as color-adjectives ("teal" vs #0F766E). For controlled lighting, include both a highlight and a shadow hex, not just the dominant color — and if the background needs a specific tone, name that hex explicitly too rather than leaving it to inference.
Mechanically: sending a plain-text prompt to generate_image runs magic prompt (the model expands it into structure on your behalf); sending the JSON caption directly is closer to magic prompt off — what you wrote is closer to what renders. For plain-text prompts specifically, put the most important subject or action first — the model weights earlier tokens more heavily, so burying the actual subject after a paragraph of mood-setting adjectives works against you.
Style extraction (reference image → new subject)
When the user has reference images and wants a new subject in the same visual language — see references/style-extraction-workflow.md for the full loop: describe_image each reference → extract the shared recipe (medium, palette, composition, texture) → apply the recipe to a new subject → generate → compare. This also works directly from a text description with no reference image at all.
Iterating on a result
- Want "more like this but—":
mcp__ideogram__remix_image, similarity tuned byimage_weight. - Want to literally change something in an existing image:
mcp__ideogram__edit_image. This is a different operation from remix/generate — if it fails, say so and stop rather than quietly falling back to a "similar" image instead.
Writing prompts generally
- Replace adjective soup ("modern, clean, professional") with things the model can actually render: an exact hex, a named medium, a real-world reference object, explicit exclusions ("no gradients, no lens flare"). A model that isn't told what to avoid tends to reach for its most common training-data default.
- One clear direction per prompt. If the user wants several options, write several structurally distinct prompts (different composition or medium, not just a palette swap on the same structure) rather than one prompt with multiple options bolted in.
- NSFW prompts get blocked outright, and plain-text prompts trigger the safety filter as false positives more often than structured JSON does — if a reasonable prompt keeps getting blocked, try the structured-caption form before assuming the request itself is the problem.