Clients cap a tool response at 1MB, and a couple of high-resolution images blow straight past that as base64 — the error is unhelpful and the fix is not obvious. Switching to file output above the threshold is the whole difference between a demo and something you can use on real work, and it is why the absolute-path and writable-directory rules are worth reading before the first run.
An MCP server over OpenAI's image generation and editing APIs, usable against api.openai.com or an Azure OpenAI deployment. Two tools, a lot of options, and one piece of plumbing that matters more than it sounds.
- `create-image` — text to image with size, quality and background options, and `n` up to 10 images in a single call
- `edit-image` — inpainting, outpainting and compositing, taking a file path or base64, with an optional mask that bounds where edits apply
- Automatic file output: anything over the 1MB tool-response ceiling is written to disk and the path returned, which is what prevents `result exceeds maximum length of 1048576`
- Azure OpenAI deployments alongside the standard API
- An `--env-file` argument so credentials can come from a file rather than the client config
`OPENAI_API_KEY`, or the Azure trio `AZURE_OPENAI_API_KEY`, `AZURE_OPENAI_ENDPOINT` and `OPENAI_API_VERSION`. Image API access needs a verified OpenAI organization, and after verifying it can take 15–20 minutes to activate. Built from source with `yarn install` and `yarn build`, then run as `node dist/index.js`. `MCP_HF_WORK_DIR` sets where saved images land, defaulting to `/tmp`. File paths passed in must be absolute, and the output directory must be writable.