A coding agent cannot generate a real raster image because it is a language model. It emits tokens, not pixels. Image models live in a separate service, and a typical coding agent has no path to that service until you attach one. Ask it for a PNG and you get a description, SVG markup, or an Artifact — all text. The fix is to give the agent a tool, over MCP, that calls a real image API and returns a hosted HTTPS URL.
Tokens are not pixels
Ask Claude Code, Cursor, or a similar agent for a product photo of a ceramic mug on wet slate. Watch what comes back. Often it is a paragraph describing the shot. Sometimes it is SVG with gradients and a circle that is supposed to be the mug. None of those is a PNG you can drop into a README.
This is not a product bug. Language models predict the next token. A PNG is a compressed grid of samples. The model has no decoder that turns its hidden state into that grid. Chat products that appear to generate images do not violate this. They call a second system — a diffusion model, or an autoregressive image model — and then show you the file. The coding agent in your editor is usually the first system only.
ChatGPT and Gemini ship a built-in image model in the chat client. Claude, on purpose, did not. The bet was code, structure, and reasoning. That is why a developer who lives in Claude Desktop or Claude Code hits this wall first.
SVG is the tempting fake. It is a complete image format that happens to be text, so the model can author it. For a simple icon or a flowchart, that can be enough. For a texture, a product shot, or a marketing still, it is the wrong file. Tutorials exist this year because Claude cannot emit a PNG on its own. Even people who like SVG as output still need a tool to close the loop.
If you want a photograph, you need an image model. The language model can write the prompt. It cannot render the pixels.
The harness has no image tool
The sharper framing is not that the model cannot see images. Many of these models reason about images just fine. The limitation is the harness around the model: the process that edits files, runs commands, and calls tools. Image generation was never wired into that toolset. There is no native image tool, so the agent improvises in the modalities it does have — prose, SVG, an Artifact.
Image generators are their own stack. Different weights, different GPUs, different request shapes. They take a prompt — and maybe a reference image, an aspect ratio, a size — and they write a file. That file has to live somewhere. The language model never sees those bytes unless you put a tool between the two.
This is why "just ask the agent" fails in IDEs even when a chat product from the same vendor can draw. Some chat clients ship a built-in image tool. Claude Desktop, Cursor, and most coding agents ship tool calling instead. If no image tool is connected, there is nothing to call.
MCP, Anthropic's open standard for exposing tools to models, closes that gap. The protocol is not the model. Swap the image model behind the tool and the workflow is unchanged: the agent fills arguments, the server talks to an API, something returns a file or a URL. The missing piece, more often than the weights, is the URL.
The DIY path is three products, not one
Building this yourself is straightforward on a whiteboard and tedious in production. You need three things, and they fail independently.
First, an MCP server. You pick a transport — stdio for a local process, Streamable HTTP for a remote one — declare a generate tool, validate arguments, map errors into something the client will show, and keep the process alive. That is a weekend if you have done it before.
Second, a model. Community servers wrap Replicate Flux, Gemini image models, OpenAI image models, fal, or a local ComfyUI instance. You sign up, store a key, pick a model id, and handle their async job protocol if they have one. Dozens of these servers exist. They still leave you holding the binary.
Third, a place to put the file. This is the step people underestimate. Many DIY servers write to disk and return a local path. That works on your laptop. It does not work in a CI runner, a teammate's clone, a GitHub comment, or a page you deploy. So you add object storage, a bucket policy, a public URL, and cache headers. Some servers return base64. That fills the context window and still is not a URL you can share. A few wrap a second upload API, which is how you end up with three keys for one image: one to generate, one to host, maybe one to strip a background.
MCP can return binary inline, but clients are picky about mime types. A hosted HTTPS URL avoids that: the client fetches a PNG the way the rest of the web already does.
Do the DIY path if you need an air-gapped GPU or a private fine-tune. For "my agent should return a PNG URL," you are assembling three products so the third one can hand you a string.
The interesting engineering is around the request
The HTTP call to an image API is the easy part. The work that actually fails in agent setups is everything around a request that sits for a while and comes back with a few megabytes of binary.
Where does the file live? How does a URL get back into the tool result, not a local path the next machine cannot see? How does the conversation keep enough context that a follow-up can point at the same asset instead of starting from scratch?
Those are storage, addressing, and session problems. They are not model problems. A community server that wraps a strong image model and then dumps the bytes into the chat, or writes a temp file, has solved the wrong half. The agent needs an address. Markdown, an img tag, a PR comment, a deployed page — the rest of the toolchain already knows what to do with an HTTPS URL.
Synchronous image generation matters here. If the generate call can wait and return the URL in the same response, the agent does not have to poll or register a webhook for the common case. Video and batch jobs take longer, so async plus a webhook is the honest contract. Mixing those up is how you get agents that sit in a loop.
The URL has to be durable enough to use. A temp file on the agent's machine is not. A CDN URL you can paste is enough.
Connecting a ready MCP server
The alternative to building those three products is to connect a server that already does all three: tool surface, model call, hosted file.
PicX is one of those. One REST API, one key with a pxsk_ prefix, Authorization: Bearer $PICX_API_KEY, base URL https://api.picxstudio.com. Roughly 33 image and video models sit behind that key. Billing is in credits per generation, never a currency amount on the meter, and you can set hard spend caps on a key so an agent cannot drain the account unattended.
Image generation is synchronous: a generate call returns a hosted image URL in the response body. There is no poll for that path. We store the file on PicX's own CDN. You do not bring a bucket. You do not configure a separate host. Video and batch jobs are asynchronous and delivered by webhook, which is the trade-off for work that cannot honestly finish in one request.
The agent-facing surface is an MCP server with 19 tools, documented at https://picxstudio.com/developers/mcp. The same platform also ships Agent Skills at /skills, a CLI, official Python and JavaScript SDKs on npm and PyPI as picx-ai, an interactive playground, live `llms.txt` and `llms-full.txt`, and `/agent-setup/prompt.md`, an executable checklist a coding agent can run. Connection pages exist for Claude Desktop, Cursor, and ChatGPT.
You add a tool schema: prompt, aspect ratio, size, maybe a reference image. The client shows the call. You approve it. A URL comes back. The agent embeds it. If the lighting is wrong, an edit tool takes that URL plus an instruction.
What you give up versus DIY: the pixels are rendered on a hosted API, so they leave your machine. If that is unacceptable, run a local model and accept that you still have to host the file. You also pay in credits, not GPU idle time. Spend caps bound the blast radius; they are not a substitute for reviewing tool calls in the client.
If you would rather skip MCP and call HTTP from a script, that is the same generate endpoint and the same hosted URL. MCP matches how coding agents already invoke tools. The REST API, the CLI, and the SDKs match a build step or a backend route.
What this does not replace
SVG is still the right output for icons, diagrams, and anything that must scale as vectors and theme with CSS. Do not route every "draw" request through an image model.
A tool also does not make the language model a designer. Bad prompts still produce bad pictures. The agent can iterate — generate, look at the URL, edit — but only if the edit path exists. That is a second tool, not a smarter system prompt.
MCP is not automatic. If the client is not connected, or you asked to find a photo instead of generate one, you will get a description again. Be explicit. Check the tool list. Generate once on purpose so you see a real URL.
FAQ
Why does my coding agent return SVG or a description instead of a PNG?
Because the model can only emit tokens. SVG and prose are token sequences. A PNG is a binary raster produced by a separate image model. Until you attach a tool that calls that model and returns a file URL, SVG and description are the honest outputs.
Do I need MCP, or can the agent just call the REST API?
Either works. A script using the picx-ai SDK or a raw POST to https://api.picxstudio.com with a Bearer key gets the same hosted URL. MCP is the interface coding agents already use to call tools inside Claude Desktop, Cursor, and ChatGPT, so you do not have to teach them an SDK in-session.
Is PicX image generation synchronous, or do I have to poll?
A simple image generate call is synchronous: the response body includes the hosted URL, and there is no job to poll. Video and batch jobs are asynchronous and delivered by webhook. Do not write a polling loop for the default image path.
How do I stop an agent from spending unlimited credits?
Set a hard spend cap on the API key, keep the key out of client-side bundles, and require tool-call approval in the MCP client while you are still prompting. Connecting the server does not bill; tools deduct credits only when they actually run.
