How MCP Image Generation Works

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 paragraphMCP 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 discoverStep 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 designStep 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 renderStep 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 honestThe 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 brieflyAuth, 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 itTry it

  • See it from the outside: the AI Agents page has the quick tour and live previews.
  • Connect and use it: the Claude MCP guide walks through a full session.
  • Call it from code instead: the API docs have tested examples in Node.js, Python, Go, and more.

Frequently Asked Questions

MCP is an open standard that lets AI assistants call external tools. A server publishes a set of tools, and any compatible client (Claude, ChatGPT, Cursor) can discover and use them mid-conversation. The Imejis MCP server exposes design and image-rendering tools, so an agent can create and render images for you.

In three moves. It discovers the component catalog, designs a template by writing structured JSON, then renders the design to a PNG or SVG in a single call. Each step is an MCP tool the agent calls, and the render returns the finished image directly.

The component catalog the agent reads is generated from the same registry the renderer validates against. When a component or property ships, the agent sees it on the next call. A drift test fails the build if the two ever disagree.

Over OAuth 2.0. The agent requests a token scoped to your account, the endpoint validates it, and every tool call acts as you. The server follows the standard MCP authorization spec, including RFC 8707 audience binding and RFC 9728 protected-resource metadata.