Loading ToolBench
MCP server for Gemini image generation API integration
Single tool with moderate naming, incomplete descriptions, and schema present but with significant gaps. Tool name 'generate_image_gemini' is verb-led and clear, but descriptions lack depth and parameter documentation is sparse. Input schema visible in code but descriptions are inconsistent in quality. Output schema is not documented. Error handling is absent from the tool definition. This server falls in the F-D range due to missing fundamental documentation patterns.
Generates an image using the Gemini Image API. Supported Models (aliases are internal): The model parameter allows selection between available image generation models. - "gemini-2.5-flash-image" (recommended default for stable, fast response). - "gemini-3-pro-image-preview". Aliases for these models are 'nano-banana 2.5' and 'nano-banana 3 Pro' respectively. Please use 'gemini-2.5-flash-image' unless the user specifically requests the Gemini 3 model.
Output schema is not documented. The function returns a dict with 'image_path' and 'message' keys, but this structure is never declared to the LLM. The tool ends with 'output_result["message"] = output_messa' (incomplete variable name), suggesting incomplete implementation. LLMs cannot plan downstream use of this tool's output without schema documentation.
Parameter descriptions are present but lack specificity and constraints. 'image_name' description states 'The filename for the output image. Defaults to gemini_output_images.png' but does not explain format constraints (e.g., must be .png, max length, allowed characters). 'output_folder' description is minimal. 'aspect_ratio' and 'image_size' have no documented constraints or enumerated valid values despite being constrained inputs (16:9, 1:1, 4:3 for aspect_ratio; 1K, 2K for image_size).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 38 | - | v1 |
No error handling or recovery guidance. The tool implementation attempts fallback behavior (saves to DEFAULT_IMAGE_DIR if target path fails), but this is invisible to the LLM. No error schema documents what failure modes are possible, which are retryable, or what the LLM should do next. A call that times out or hits a rate limit will return opaque failure to the agent.
Model parameter description is verbose and includes example values ('nano-banana 2.5', 'nano-banana 3 Pro') which LLMs tend to reuse literally. Description should be shorter and rely on an enum constraint instead: allowed values are 'gemini-2.5-flash-image' and 'gemini-3-pro-image-preview'.
Prompt parameter has a default value ('A detailed, cinematic image of a futuristic city.') which is an example that LLMs may reuse instead of adapting to user intent. Default should be null or omitted, forcing the agent to provide user context.
Tool description is approximately 350 characters, which is acceptable, but lacks critical context: When should this tool be called vs. other image generation tools? What are the prerequisites (e.g., valid API key must be configured)? What are realistic latency expectations? Does this tool support retry on rate limits? This lacks the WHEN and HOW context needed for robust agent selection.