Image Generation MCP Server: Connect It to Claude & Cursor

An image generation MCP server lets an AI agent create images by calling a tool, instead of you typing prompts into a web form. Connect one to Claude, Claude Code, or Cursor, and the agent can generate a hero shot, a set of product mockups, or a batch of thumbnails in the middle of a conversation, then hand you the files. This guide connects one end to end, using the Dream Pixel Forge server as the worked example.

Search for “image generation MCP server” and you get a wall of directory listings and bare GitHub repos, almost all of them the same thing: a thin wrapper around one text-to-image model. That works for a one-off picture. It falls apart the moment you want output that matches a brand, an agent that does not silently burn through your account, or images that get checked before they reach you. The difference between a passthrough server and an agent-native one is the whole point of this post, so we will cover both the setup and what actually separates them.

What is an image generation MCP server?

The Model Context Protocol (MCP) is an open standard that Anthropic introduced in November 2024 to standardize how AI applications connect to external tools and data. An MCP server exposes a set of tools; an MCP client (the app running the model) discovers those tools and lets the model call them. It is the same idea as a USB port for AI: implement the protocol once, and any compliant client can plug in.

An image generation MCP server is simply an MCP server whose tools create images. Once it is connected, the model can call a tool like generate_image during a normal chat, get back an image URL, and keep working. You never leave the agent to visit a separate site.

There are two kinds in the wild, and they are not close in capability:

• Raw passthrough servers. One tool, usually named something like generate, that forwards a prompt to a single model (OpenAI's image API, a Gemini or FLUX endpoint) and returns the result. This is what most of the GitHub and directory listings are. Fine for a quick picture, blind to your brand, and happy to keep generating as long as the agent keeps asking.
• Agent-native servers. A set of tools that give the agent brand context, server-enforced spend limits, and a way to check its own output before you see it. Dream Pixel Forge is built this way, because the product is agents doing real creative jobs, not a single API call dressed up as a tool.

What you need before you connect

Three things, and two of them you likely already have:

• A Dream Pixel Forge account. The free tier is enough to test the connection and generate on the image models; paid plans add video and higher throughput.
• An MCP-capable client. Claude Code, the Claude desktop app, claude.ai connectors, Cursor, Codex, and ChatGPT all speak MCP. Any of them works.
• An API key. You mint one with dpf login, which opens your browser to approve the machine. The plaintext key never leaves your computer: only its SHA-256 hash is sent to the server, so an approved key cannot be read back out of your account. For headless or CI use, set the DPF_API_KEY environment variable instead.

The endpoint is the same for every client: https://www.dreampixelforge.com/api/mcp. It is a stateless Streamable HTTP endpoint, the standard transport for remote MCP servers, and it authenticates with your key as an Authorization: Bearer header.

How to connect the image generation MCP server

The setup is a one-line command or a small block of JSON, depending on the client. Get your key ready first (run dpf login, or mint one from your account), then pick your client below. Keys look like dpf_ followed by 64 hex characters.

Claude Code

Use the claude mcp add command with the HTTP transport and an authorization header:

claude mcp add --transport http dream-pixel-forge \
  https://www.dreampixelforge.com/api/mcp \
  --header "Authorization: Bearer dpf_your_key_here"

That registers the server for the current project. Add --scope user to make it available in every project on your machine. Run /mcp inside Claude Code to confirm the tools loaded, then ask it to generate something.

Cursor

Cursor reads MCP servers from .cursor/mcp.json (per project) or ~/.cursor/mcp.json (global). Add the server with its URL and header:

{
  "mcpServers": {
    "dream-pixel-forge": {
      "url": "https://www.dreampixelforge.com/api/mcp",
      "headers": {
        "Authorization": "Bearer dpf_your_key_here"
      }
    }
  }
}

Reopen Cursor settings and the server appears under MCP with a green dot once it connects.

Claude desktop app and claude.ai connectors

In the Claude desktop app and on claude.ai, add it as a custom connector and paste the endpoint URL. Some connector surfaces cannot attach a custom header; for those, the server also accepts the key as the final path segment of the URL, https://www.dreampixelforge.com/api/mcp/dpf_your_key_here. That form works everywhere but puts the key in the URL, which is more likely to end up in a log, so prefer the header when the client supports it.

The agent-native workflow: run, plan, generate, validate

Once connected, the agent sees a set of tools that walk it through a real creative job rather than a single shot. The intended loop is five steps:

1. create_run starts a job from a brief (“launch sheet for the spring capsule”), optionally tied to a moodboard.
2. update_run stores a concept plan before anything is generated. The agent has to commit to what it intends to make first.
3. generate_image produces one image per planned concept. It can take a template, a freeform prompt, an aspect ratio, and up to six reference images.
4. vision scores the generated image against the brief and your brand on separate axes, so the agent can catch a near-miss and redo it before you ever look at it.
5. get_run reports status, credits spent, and fresh image URLs at any point.

That vision step is the part raw servers do not have. The agent is judging its own output with a vision model and iterating, which is why what lands in your review is finished work rather than raw attempts. The full server also exposes generate_video, get_brand_profile, get_influencers (your saved AI personas), get_board_context, get_templates, and propose_brand_fact, so an agent can pull real context before it generates and file what it learns for you to confirm.

Why this beats a raw text-to-image MCP server

A passthrough server treats every request as if it were the first one it had ever seen. It has no idea what your brand looks like, no cap on how much it spends, and no opinion on whether the image it just made is any good. For a developer building a real workflow, three things change with an agent-native server:

• Brand context is served, not re-typed. get_brand_profile and get_influencers hand the agent your compiled brand block, reference images, and saved personas. Output matches your style without you describing it in every prompt, and a locked persona keeps the same face across a whole set of images.
• Spend limits the agent cannot bypass. Every generation debits your credit balance in a server-side transaction, each API key has a daily limit on credit-spending calls, and each planned concept allows one regeneration at most. An over-eager agent that decides to generate forty variations runs into limits it cannot talk its way past.
• The agent checks its own work. The vision validate mode is a self-review step. You review approved results, not every raw generation.

None of that exists in a one-tool wrapper. If you only ever want a single decorative image, the wrapper is fine. If you want an agent to produce on-brand work at volume without babysitting, the context, the spend limits, and the self-check are the reason to choose an agent-native server.

Which image and video models can the agent call?

You do not pick a model per request; the server routes each job to the cheapest model that clears the quality bar, with a fallback chain if a provider is down. The image models it can reach include xAI's Grok Imagine, Google's Nano Banana 2 (with a faster Lite and a higher-fidelity Pro variant), OpenAI's GPT Image 2, and FLUX Kontext Pro for identity-preserving edits. For a deeper comparison of these engines, see our guide to the best AI image generators.

Video runs through the same run over generate_video, routed across Google Veo 3.1, ByteDance Seedance 2.0, and xAI Grok Imagine Video. It renders in the background, so the agent kicks off the clip and polls get_run until the URL is ready. If you are new to animating stills, our image to video AI guide covers why generating the frame first and animating it second is the cheaper path.

How credits and spend limits work

Generation spends credits, the same currency as any other work in the studio, and images are cheap: they run from 2 credits on the fast models up to 8 on the highest-fidelity one. A new account starts with a signup credit grant, and the free tier covers the image models (video is a paid-plan feature). Your balance is the hard ceiling — an agent can never spend credits you do not have — and per-key daily limits bound what an unattended agent can spend in a day. See the pricing page for current credit packs and per-plan allowances.

Using it without MCP: the dpf CLI

Not every coding agent connects over MCP. If yours drives a terminal, it can use the same account through the dpf command-line tool, which talks to the same endpoint over HTTP:

npm install -g dreampixel-cli   # or: npx dreampixel-cli
dpf login                        # approve this machine in the browser
dpf skill install                # teach a coding agent the full workflow

The dpf skill install command writes a skill file into .claude/skills/ that teaches an agent the create, plan, generate, validate loop and the credit costs in one step. From there the agent runs dpf run create, dpf generate, and dpf vision the same way it would call the MCP tools. The full setup and the copy-paste agent prompt live on the agentic creation page.

The bottom line

Connecting an image generation MCP server takes one command. Choosing the right one takes a minute of thought: a raw passthrough gives your agent a single picture, while an agent-native server gives it brand context, a spending cap, and a self-check, which is what you need for an agent that does creative work you can actually ship. Get a key with dpf login, point your client at the endpoint, and let the agent take the brief.