MCP server for AI image generation (Gemini / Nano Banana) and upload to S3-compatible storage (Cloudflare R2, AWS S3, MinIO). Works with Claude Code, Cursor, Codex, and any MCP client.
Three tools with complete input schemas and descriptions. Naming follows verb_noun pattern (generate_*, upload_*). Descriptions are detailed (150-250 chars) and explain prerequisites. All parameters have types and descriptions. However, output schemas are not documented in the visible code, only inferred from descriptions. Error handling is mentioned in descriptions but not formalized in the schema. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present.
Generate an AI image with Gemini (Nano Banana) and upload it to S3-compatible storage in a single call. Returns the public URL and a thumbnail preview. This is the most common workflow when you need a public URL for a generated image. Requires both GEMINI_API_KEY and S3_* environment variables.
Generate an AI image using Google Gemini (Nano Banana) or Imagen 3. Returns the absolute path of the saved file plus a thumbnail preview. Does NOT upload — use upload_image_s3 or generate_and_upload_gemini_s3 if you need a public URL.
Upload a local image file to S3-compatible storage (Cloudflare R2, AWS S3, MinIO, DigitalOcean Spaces, etc.) and return the public URL. Requires S3_* environment variables to be configured.
Output schemas not documented. Tool descriptions mention return values ('returns the absolute path', 'returns the public URL') but no formal output schema is visible in the code. LLMs cannot plan downstream tool calls without knowing the exact response structure.
Tool naming combines multiple actions: 'generate_and_upload_gemini_s3' violates single-responsibility principle. While documented as 'the most common workflow', it couples image generation with S3 upload, making it harder for agents to compose workflows flexibly.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All three tools perform WRITE operations (file generation, S3 upload) but lack destructiveHint annotation. Agents cannot distinguish safe reads from state-modifying calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Error handling not formalized. Descriptions mention 'S3 not configured' and 'helpful error' but no error response schema or recovery guidance is visible. LLMs need explicit error categories (retryable, user-fixable, fatal) to plan recovery.
Parameter 'output_dir' accepts arbitrary paths with no validation hints. Description says 'Absolute path' but no constraints on traversal, permissions, or disk space. LLMs could pass invalid paths, causing silent failures.