Server for generating images using Gemini API with Imagen 3
Single tool with decent naming and basic parameter documentation, but significant gaps in descriptions, no output schema documentation, and critical missing error handling guidance. The tool is explicitly registered with Zod schema validation and descriptions present, but falls short of production quality expectations. Parameter descriptions are sparse (e.g., 'Aspect ratio of the image (e.g., '1:1', '16:9')' lacks constraints and validation rules). Output schema is completely undocumented, LLMs have no guidance on what fields to expect in the response. Error handling is minimal: the catch block returns unstructured text rather than actionable recovery guidance. The server lacks any mention of deprecated patterns (Sampling, Roots, Logging, DCR, ping) and properly omits them, but this is baseline correct behavior, not a bonus.
Generate an image using Gemini API
Tool description is too brief (27 characters) and lacks WHEN to use, prerequisites, and side effects. Should state that this modifies external state (generates and may write to disk).
Output schema is completely undocumented. Response includes image data (base64) and mime type, but LLMs have no guidance on expected fields, structure, or when image vs text is returned.
Parameters lack proper constraints and validation guidance. 'aspectRatio' should be an enum (e.g., '1:1', '16:9', '4:3') rather than free-form string. 'outputFormat' should be an enum ('png' | 'jpeg'). Current design invites hallucinated values.
Error handling returns plain text error message instead of structured guidance. Catch block returns 'Error generating image: {error.message}' which gives LLM no actionable recovery path. Should categorize errors (retryable vs user-fixable) and suggest next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Side effect not documented: tool writes to disk ('gemini-native-image.png') and returns base64 image data. LLMs should know this modifies filesystem state and understand that repeated calls with same prompt may overwrite previous output. No idempotency guarantee stated.
Parameter 'prompt' defaults to 'Default image prompt' if falsy, but Zod schema marks it as required (z.string()). This creates a mismatch: schema says required, implementation allows null/undefined. Either enforce strictness or document the fallback behavior.
No pagination, batch, or result limiting guidance. If image generation is slow or expensive, returning raw response without timeout, retry limits, or rate-limit hints could cause agent hangs or cost overruns. Should document timeout, cost, and rate-limit expectations.