Loading ToolBench
MCP server for OpenAI GPT Image API - Generate and edit images using gpt-image-1, gpt-image-1.5, and gpt-image-2
This server demonstrates solid definition quality with comprehensive schema coverage, detailed parameter documentation, and clear tool-specific descriptions. All 12 tools have explicit schemas and descriptions. However, there are notable gaps in error handling guidance, output schema documentation, and some parameter descriptions lack actionable constraint details. The server follows good naming conventions (verb-noun pattern) and provides extensive parameter validation via enums. Tool descriptions are substantive (averaging ~180 chars) and explain what each tool does, but lack recovery guidance and error classification. Schema quality is strong with proper JSON Schema format, types, and enum constraints throughout. Main weaknesses: (1) no output schema documentation for any tool, LLMs cannot predict response structure; (2) minimal error guidance; (3) some parameters like 'directory' in list_generated_images lack format or path validation hints; (4) no documented mutually-exclusive parameter relationships (e.g., reference_image_base64 vs reference_image_path). Despite these gaps, the server is well above the median community MCP server (which typically scores 45-55) due to consistent schemas, descriptive text, and thoughtful parameter design.
Cancel a running or pending asynchronous image generation job.
Check the status of an asynchronous image generation job. Returns current status, progress percentage, and additional job information.
Edit an existing image using inpainting with OpenAI GPT image models. Requires a reference image and optional mask image (transparent areas are edited). gpt-image-1.5 supports input_fidelity for better face/logo preservation.
Generate a new image from a text prompt using OpenAI GPT image models. Supports gpt-image-1, gpt-image-1.5 (4x faster/cheaper, better text), and gpt-image-2 (flexible sizes up to 4K). Automatically calculates and reports token usage and cost.
Retrieve detailed information about a previously generated image from the history database using its UUID.
Retrieve the result of a completed asynchronous image generation job, including output file paths and generation metadata.
No output/response schemas documented for any tool. LLMs cannot predict the structure of results (e.g., does generate_image return a file path, base64 string, or object with metadata?). This forces LLMs to guess about downstream tool parameters and invokes trial-and-error behavior.
Mutually exclusive parameters not documented. edit_image and transform_image each accept both 'reference_image_base64' and 'reference_image_path', but LLM behavior when both are provided is undefined. Parameter descriptions should state: 'Provide EITHER reference_image_base64 OR reference_image_path, not both.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Extract and display embedded metadata from a generated image file, including UUID, parameters hash, generation parameters, and database record information.
List all generated images in a directory. Returns a list of image files that were generated by the MCP server.
List generation history from the database. Returns a list of previously generated images with their parameters and metadata.
List asynchronous image generation jobs with optional filtering by status or tool name.
Start an asynchronous image generation job. Supports generate_image, edit_image, and transform_image operations. Returns a job ID that can be used to monitor progress and retrieve results.
Transform an existing image to a new style or interpretation using OpenAI GPT image models. Takes a reference image and a prompt describing the desired transformation. gpt-image-1.5 supports input_fidelity for better face/logo preservation.
Error handling and recovery guidance absent. No parameter descriptions indicate what errors are retryable, what constitutes user-fixable input, or what the LLM should do if generation fails. E.g., 'If moderation rejects the prompt, try a different phrasing' or 'Retry with exponential backoff if rate limited.'
start_generation_job accepts only 'tool_name' and 'prompt' as required params, but omits all other configuration options (model, size, quality, etc.). This forces LLMs to either call start_generation_job with minimal control or use synchronous tools instead. Job tool should mirror main tool parameters or provide documentation on default behavior.
Parameter descriptions for 'directory' (list_generated_images) and 'image_path' (get_metadata_from_image) lack format guidance. Should specify: 'Absolute or relative path from current working directory' or 'Must be a valid filesystem path (no URLs or symbolic references).'
Limit parameters (list_history, list_jobs) lack validation constraints in descriptions. Should state: 'limit must be 1 - 100' or 'offset must be >= 0'. Current descriptions omit min/max bounds, forcing LLMs to guess or cause API errors.
No pagination documentation. list_history and list_jobs accept limit/offset but descriptions don't state whether results are guaranteed complete or if there's a total count in the response. Lack of clarity on result boundaries risks silent truncation.
sample_count parameter description in generate_image, edit_image, transform_image lacks context on cost impact or availability per model. Should clarify: 'Note: Generating multiple samples increases API cost proportionally. gpt-image-2 may have per-sample restrictions.'