codex-image-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEX_BIN | No | Path to the Codex CLI binary. Use this when the `codex` executable is not available on `PATH`. | |
| CODEX_HOME | No | Codex home directory; generated PNGs are picked up from `$CODEX_HOME/generated_images/<thread>/`. If unset, the Codex CLI default is used. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generate_imageB | Generate one image with Codex's built-in image tool on the signed-in ChatGPT plan. Takes ~30-60 s and counts against the plan's Codex usage limits. output_path: absolute path ending in .png; existing files are kept unless overwrite=true. reference_images: local image paths Codex should follow for design, palette or style. reasoning_effort: Codex effort before calling the tool ("low" is fastest). |
| generate_imagesB | Generate several images in parallel (e.g. every pose of a sprite set). jobs: list of {"prompt", "output_path", optional "reference_images" and any per-job override of the shared options}. concurrency: parallel Codex runs (default 3; higher may hit rate limits). Returns one result per job in order; failed jobs carry "error". |
| edit_imageA | Edit only one region of an image; every pixel outside it stays identical to the original. Pass exactly one region:
|
| normalize_framesA | Turn separately generated frames into one consistent sprite set (no Codex call, instant). Frames need a transparent background (generate them with chroma_key). Each frame is scaled so the character's body area (ignoring thin parts like a pick handle) matches reference_path, which keeps the same size whether the pose stands, crouches or lunges. Frames are anchored on a shared feet baseline and centre on one canvas, given hard alpha, and snapped to up to palette_size of the reference's own colours (0 keeps the generated colours). Writes <output_dir>/.png and returns each frame's scale and body height, the shared canvas size and the anchor (feet point) for the engine's sprite offset. |
| login_statusA | Report whether Codex is signed in and which ChatGPT plan it uses (plus, pro, ...). |
| start_device_loginA | Start a ChatGPT device-code login for Codex and return the URL and one-time code. The user opens the URL, enters the code and approves; then call login_status to confirm. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct action: single generation, batch generation, region edit, frame normalization, and two login operations. The only near-pair is generate_image vs generate_images, but the singular/plural framing plus the jobs/concurrency description make the boundary clear. login_status vs start_device_login is also cleanly separated by status-vs-initiate semantics.
Consistent snake_case with verb_noun ordering (generate_image, edit_image, normalize_frames, start_device_login). The one minor deviation is login_status, which is noun-only rather than a verb form like check_login_status, but it stays readable and predictable.
Six tools is well-scoped for an image generation/editing server: generation, batching, editing, post-processing, and login are each covered once. No tool feels redundant or padded.
The core lifecycle (login, generate, batch generate, edit, normalize frames) is covered, but normalize_frames' description tells users to 'generate them with chroma_key' — a tool that does not exist in this set, leaving a dead end for transparency generation. There is also no way to inspect an existing image or verify plan usage despite usage limits being emphasized throughout.