GPTImage

Ask Claude for a picture. Get one back, inline.

An MCP server that bolts OpenAI's gpt-image-2 onto Claude so you can stop alt-tabbing between two chat windows. No browser automation, no scraping a web UI, no cursed Selenium rig held together with duct tape. Just the real API, wrapped in the Model Context Protocol.

MCP Server GPL-3.0 C++20

Three tools, and no more.

Two do the work and a third fetches a slow render. Scope creep is how projects die in a ditch.

gptimage_generate

Text goes in, image comes out. Set quality to low when you are spitballing and high when it is going in the deck. auto and medium exist for the indecisive.

gptimage_edit

Hand it one or more images plus a prompt and it edits or combines them. Pass a mask for surgical inpainting instead of regenerating the whole thing and hoping.

gptimage_result

A high-quality render can take a couple of minutes, longer than a connector will sit and wait. The other two hand back a job id and this fetches the finished image once it is ready.

The picture lands where you can see it.

Images come back as WebP, a few dozen kilobytes instead of a multi-megabyte PNG that a remote connector quietly drops on the floor.

Over a remote connector the server also hosts each render for a few minutes and hands Claude a link, so the picture appears inline in the conversation body rather than collapsed inside a tool-call widget you have to expand. Locally over stdio there is nothing to host, so the image rides back inline as base64 and the client renders it.

The part you will ignore until it bites you.

This thing spends real money. Every high-quality 1024x1024 render is roughly twenty cents of somebody's OpenAI bill, and that somebody is you.

It is single-tenant by design: your key, your box, your problem. There is a max_n cap so an over-caffeinated agent cannot loop itself into bankruptcy in a single call, but the only cap on quality and frequency is your own self-control. Godspeed.

Where prompts and renders go.

Prompts and reference images go from your machine to OpenAI using your own API key. Locke Werks runs no service in this path and receives nothing.
Your API key lives in the OPENAI_API_KEY environment variable. It never goes in a config file. If you paste your key into a TOML and commit it, that is a you problem.
Nothing you generate touches the disk. A finished render lives in memory only long enough for the client to fetch it, served from an unguessable per-render URL and then dropped.
The PostgreSQL database holds only auth plumbing: bearer tokens, OAuth clients, codes and refresh tokens. It never stores an image.
Run locally over stdio and the database is never even opened. Auth is off because stdio trusts the OS boundary, and the tools only talk to OpenAI.

Local, or properly hosted.

For local use, point your MCP client at the binary over stdio with your API key in the environment. That is the whole setup.

For remote use it ships an embedded OAuth 2.1 authorization server, so adding it to claude.ai as a custom connector just works: point it at your host and sign in on the built-in login page. The repository includes a hardened systemd unit, a Caddy site block that terminates TLS and 404s everything it should, fail2ban jails for the login and registration endpoints, and a deploy script that health-checks the new build and rolls itself back if it faceplants.