Stdio MCP server for OpenAI gpt-image-2 and Google Gemini image generation.
Two tools with complete input schemas and descriptions, but descriptions are verbose (500+ chars) and lack LLM-optimized structure. generate_image has good parameter coverage (prompt, model, size, input paths/URLs, output_dir) with enums for model and size. check_image_job is minimal but functional. Both tools document their purpose and return format in prose, but descriptions bury key details in walls of text. No parameter-level descriptions visible in schema (only top-level descriptions). Error handling is present (error status in job tracking) but recovery guidance is minimal. No tool annotations (readOnlyHint/destructiveHint) despite generate_image being destructive (WRITE risk). Output schema is documented in prose but not formally specified.
Poll for the result of a generate_image call. Returns the same format as generate_image: either a done status with the file path + thumbnail, a pending status with a hint to wait, or an error status.
Generate or edit an image. Writes the PNG to disk and returns the file path AND an inline JPEG thumbnail content block. Models: 'gpt' (OpenAI gpt-image-2; default; best for editorial / brand photography and literal text rendering); 'gemini' / 'gemini-flash' (gemini-3.1-flash-image-preview, a.k.a. Nano Banana; good multi-image composition, character consistency, fast); 'gemini-pro' (gemini-3-pro-image-preview, highest Gemini quality but preview-tier capacity — can 503 under load). Reference images: pass local file paths in `input_image_paths` (preferred) or http(s) URLs in `input_image_urls`. Never embed base64 — LLMs corrupt long opaque strings and providers reject them. Returns the full-resolution PNG path + an inline JPEG thumbnail. Most generations complete within 30–90s; complex prompts can take up to 2 minutes. Call check_image_job to poll for completion.
Descriptions are verbose (500+ chars) and lack LLM-optimized structure. Key details (model differences, timeout behavior, file path guidance) are buried in prose. Descriptions should be 50-200 chars with constraints in parameter descriptions, not tool descriptions.
No parameter-level descriptions visible in input schemas. Schema shows parameter names and types (prompt, model, size, input_image_paths, input_image_urls, output_dir) but descriptions are missing from the JSON Schema object. LLMs cannot infer that 'model' selects between OpenAI/Gemini or that 'size' must be one of the enum values.
No tool annotations despite clear risk profiles. generate_image is marked WRITE (destructive, writes to disk) but lacks destructiveHint annotation. check_image_job is READ_ONLY but lacks readOnlyHint. Annotations guide agent behavior and safety policies.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Output schema not formally documented. Tool descriptions mention 'returns the full-resolution PNG path + an inline JPEG thumbnail' and 'either a done status with the file path + thumbnail, a pending status with a hint to wait, or an error status', but no structured schema (JSON Schema or TypeScript interface) is visible in the tool definition. LLMs must infer output structure from prose.
Error recovery guidance is minimal. When generate_image fails, the error is stored as a string (job.error) and returned as plain text. No actionable guidance (e.g., 'Retry with a simpler prompt', 'Check API quota', 'Verify input image format'). check_image_job returns pending status with a hint to wait, but no guidance on max retries or backoff strategy.