Loading ToolBench
An MCP server that generates, edits, and creates variations of images using OpenAI's gpt-image-1 model
The server defines 2 tools with complete input schemas and reasonable descriptions. Both tools (generate_image, edit_image) follow verb_noun naming convention and document their parameters with types and descriptions. However, there are significant gaps in output schema documentation, error handling guidance, and some parameter descriptions lack actionable constraints. The tool descriptions are functional but could be more LLM-optimized. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite both tools being WRITE operations.
Edits an image or creates variations using OpenAI's gpt-image-1 model and saves it. Can use multiple input images as reference or perform inpainting with a mask.
Generates an image using OpenAI's gpt-image-1 model based on a text prompt and saves it.
Output schema not documented. Tools return unstructured dicts with 'status', 'saved_path', or 'message' keys, but no formal schema is declared. LLMs cannot plan downstream operations or validate responses.
Missing tool annotations despite both being destructive WRITE operations. No idempotentHint, destructiveHint, or readOnlyHint. Agents cannot reason about retry safety or side effects.
Error handling lacks recovery guidance. Errors return bare messages like 'API call succeeded but no image data received' or 'Failed to save image: <exception>' without suggesting next steps. LLM cannot act on these.
Parameter descriptions lack format/constraint clarity. Example: 'size' enum is documented but no guidance on what each size produces or when to choose 'auto'. 'quality' parameter similarly vague about actual rendering differences.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
edit_image parameter 'image_paths' requires PNG format and <25MB per image, but no validation is documented in the parameter description itself. Format and size constraints buried in docstring, not in schema or param descriptions.
No idempotency or dry-run support for irreversible operations. Both tools modify the file system (write/overwrite images). No confirmation step or retry guidance for partial failures.
Timeout handling not documented. Tools call external OpenAI API but no explicit timeout or timeout error guidance is visible in code review. Hung API calls could block agents indefinitely.