--- title: "How MCP Image Generation Works" description: "A look under the hood of the Imejis MCP server: how an AI agent discovers components, designs a template, and renders a real image, and why the catalog can never drift from the renderer." url: "https://www.imejis.io/blogs/tutorials/how-mcp-image-generation-works" published: "2026-07-25" --- # How MCP Image Generation Works When an AI agent renders an image with Imejis, it looks like magic in the chat: you ask, a finished graphic comes back. Underneath, it's three plain steps over the Model Context Protocol. Discover, design, render. Here's how each one works, and the one design decision that keeps the whole thing honest. ## MCP in one paragraph MCP is an open standard for connecting AI assistants to external tools. A server publishes a set of tools with typed inputs. A client like Claude, ChatGPT, or Cursor connects, reads the tool list, and calls them during a conversation. The Imejis MCP server is a stateless Streamable HTTP endpoint that publishes tools for working with your designs. Nothing about it is specific to one AI vendor; any compliant client can drive it. ## Step 1: Discover The agent can't design anything until it knows what pieces exist. So the first tool it reaches for is the catalog. `list_component_types` returns every component the renderer supports: text, images, QR codes, barcodes, tables, and a dozen chart types, each with its properties, allowed values, defaults, and a ready-to-render sample. `get_design_guide` returns the same information as prose, for models that reason better over a written spec. Here's the important part. That catalog isn't a hand-written document that someone remembers to update. It's generated at request time from the component registry, which is the exact source of truth the renderer uses to validate a design. Ship a new component or a new property, and the agent sees it on the very next call. There's no second copy to forget. ## Step 2: Design Now the agent builds. A design in Imejis is a JSON document: canvas dimensions, a background, and an ordered list of components. Each component has a type, a position, a size, and type-specific properties. The agent has a few tools here: - `create_design` for a blank canvas, or `create_design_from_template` to start from something real - `update_design` to write the full document, read-modify-write style - `preview_design` to render a small check image and look at its own work before committing That preview step matters more than it sounds. It closes the loop. The agent isn't writing JSON blind and hoping; it renders a thumbnail, sees the result, and fixes the headline that overflowed or the color that clashed. It's the same edit-and-look cycle a person uses in the editor, just driven by a model. ## Step 3: Render Once the design is right, the agent renders it. Two tools cover the two shapes this takes. `export_design` renders once and returns the finished image. Good for a one-off, or when the agent is producing a specific graphic in the conversation. `get_render_url` returns a permanent URL that renders fresh on every request. This is the one that scales. The agent designs a template with dynamic fields, hands you a URL, and every downstream call swaps the data: a different name, a new price, the next row of a spreadsheet. One template, unlimited images, no re-rendering by hand. Overrides use a simple `component.property` convention. To change a headline's text you send `headline.text`. To recolor it, `headline.color`. The agent reads a design's exact field names over MCP, so the overrides it writes are correct the first time. ## The decision that keeps it honest Most "AI can use our tool" integrations rot. The tool changes, the docs describing it to the model don't, and the agent starts calling things that no longer exist. Imejis avoids that by generating the agent-facing catalog from the renderer's own registry, and then guarding the boundary with a test. The MCP layer keeps a validation mirror so it can check a design before sending it, and a drift test renders every component's sample through that mirror on every build. If the catalog and the renderer ever disagree, the build fails. An agent can't be told about a component that won't render, and it can't be kept in the dark about one that will. That's the whole trick to a durable agent integration: one source of truth, generated outward, guarded by a test. ## Auth, briefly Every tool call acts as you, so authentication matters. The agent gets a token over OAuth 2.0, scoped to your account. The endpoint validates it the same way the normal API does, and follows the standard MCP authorization spec, including RFC 8707 audience binding and RFC 9728 protected-resource metadata, so compliant clients connect without custom glue. Renders count against your plan the same as a direct API call. ## Try it - **See it from the outside:** the [AI Agents](/agents) page has the quick tour and live previews. - **Connect and use it:** the [Claude MCP guide](/blogs/tutorials/generate-images-claude-mcp) walks through a full session. - **Call it from code instead:** the [API docs](/apis) have tested examples in Node.js, Python, Go, and more.