Loading ToolBench
MCP server for generating and editing images with Google Gemini for web development
The server defines two image manipulation tools with reasonable descriptions and parameter documentation. Both tools have complete JSON Schema input definitions with type information and parameter descriptions. However, there are several quality gaps: (1) Tool descriptions contain prescriptive guidance about checking project paths, but lack clarity on what the tools actually return; (2) Parameter descriptions are adequate but lack format constraints, ranges, and validation rules; (3) No output schemas are documented, forcing LLMs to infer result structure; (4) Tool names are verb-based but generic ('generate_image', 'edit_image') without distinguishing between use cases; (5) The 'aspectRatio' and 'resolution' parameters accept enums but descriptions don't clearly list all valid values inline; (6) No error handling guidance is provided, LLMs won't know how to recover from API failures, invalid paths, or unsupported formats. Overall, the definitions are functional but lack the polish and completeness expected of A-grade tools.
Edit an existing image using Google Gemini. IMPORTANT: Before calling this tool, determine the correct output path in the user's project. Provide the source image path and describe what changes to make.
Generate an image using Google Gemini. IMPORTANT: Before calling this tool, determine the correct output path in the user's project (e.g., public/images/, src/assets/, etc.). Supports aspect ratio presets (hero, square, portrait, landscape, banner, mobile) or explicit ratios (16:9, 1:1, etc.), and resolutions (1K, 2K, 4K).
No output schema documented for either tool. LLMs cannot infer what fields are returned (e.g., image URL, file path, dimensions, generation metadata). This forces agents to guess and makes downstream tool composition impossible.
Tool descriptions contain implementation guidance ('determine the correct output path in the user's project') but lack clarity on what the tool actually returns or when to use it vs the other. No explicit statement of success/failure behavior or result structure.
The 'aspectRatio' parameter description states 'Preset or explicit ratio' and mentions examples, but does not enumerate all valid values. LLMs cannot discover that 'hero' maps to '16:9' or that '21:9' is valid without reading server code. Valid values should be listed in the description or as enum constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
The 'resolution' parameter description states 'Output resolution: 1K (default), 2K, or 4K' but does not use enum constraints. Free-form string parameters invite LLMs to hallucinate invalid values like '5K' or 'Ultra HD'.
No error handling guidance provided. If Gemini API fails, the path is invalid, or the reference image format is unsupported, LLMs have no recovery strategy. Error responses must tell the agent what to do next (retry, try a different path, simplify the prompt, etc.).
The 'outputPath' parameter description requires users to pre-determine the correct directory, but provides no tool to discover available directories or validate paths. This forces agents into a pre-planning loop when they could delegate path discovery to the tool.
Tool names 'generate_image' and 'edit_image' are generic and do not indicate the underlying capability (Google Gemini, generative AI). When many image tools exist, naming should be more specific (e.g., 'generate_image_gemini', 'inpaint_image_gemini') to avoid LLM confusion. Additionally, neither tool name indicates they accept reference images, which is a key differentiator.