Loading ToolBench
MCP server for AI-powered image generation using Google Gemini models.
Single tool 'generate-image' has a well-structured schema with proper enums and type constraints. Description is comprehensive (280+ chars) and explains storage behavior, output modes, and usage guidance. All 5 parameters are typed and described. However, the tool combines multiple concerns (generation + storage + format selection), and error handling relies on text responses rather than structured error objects. Output schema is documented in description but not formally specified. Naming is clear and verb-forward.
Generate an image from a text prompt using Google Gemini. Storage provider: Cloudinary or Azure Blob Storage (if configured). The response contains a URL and base64 image data. Always decode the base64 from disk and use present_files to show the image in chat. Never load the raw base64 into context. Use the URL for any subsequent image generation calls as file_data input.
Output schema not formally documented. Tool returns JSON strings embedded in text content rather than structured response objects. LLMs must parse JSON from text, increasing error likelihood.
Error handling returns text-wrapped JSON without structured error classification. No guidance on retryability, user-fixable vs fatal errors, or recovery steps. 'Error: outputType only-url requires storage' is bare; should indicate this is user-fixable and suggest alternatives.
Tool combines image generation, storage provider selection, and output format control in one tool. Consider splitting: generate-image (core) + configure-storage (setup). Current design forces LLM to reason about storage availability on every call.
Parameter 'outputType' has complex interdependencies (only-url requires storage, only-image always works) documented in description but not enforced. LLM may pass invalid combinations; tool returns error instead of preventing it.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
No pagination or result limiting documented. If base64 image data is large (4K images can exceed 5MB), returning it in every response wastes tokens. Tool description advises 'decode from disk' but no mechanism provided.