Model Context Protocol server for Google AI image generation using Gemini and Imagen models
The server defines 9 tools with generally adequate descriptions and schema coverage, but several tools lack depth in parameter documentation and output schema specification. Tool naming is action-verb based and mostly clear (generate_image, edit_image, list_image_models), though some names could be more specific. Descriptions are present for all tools and range from 50-180 characters, meeting the baseline minimum but often lacking the LLM-optimized context that would improve selection accuracy. Parameter schemas are consistently defined with type information, but descriptions for individual parameters are often generic or missing rationale. No documented output schemas, error handling guidance, or recovery paths. Security concern: the server accepts API key via environment variable (good) but tool descriptions do not mention prerequisites or permission requirements. Composition is reasonable, tools have single responsibilities, but chaining is not optimized (e.g., set_image_model must be called before generate_image, but this dependency is only mentioned in descriptions, not enforced).
Check if the Google AI API key is configured and valid. This tool validates the API configuration by attempting to list available models. Use this to verify your setup before generating images.
Convert an image to a different format. This tool converts an image file from one format to another (e.g., PNG to JPEG).
Edit an existing image using Google AI (Gemini/Imagen). This tool applies modifications to an existing image based on a text description. The image can be provided as a file path or base64-encoded data.
Generate an image using Google AI (Gemini/Imagen). This tool generates images based on text prompts using Google's AI models. Make sure to set a model first using 'set_image_model' or provide one here.
Generate an image using Google AI with one or more reference images. This tool generates images based on text prompts and visual references. Up to 3 reference images can be provided.
Missing documented output schemas for all 9 tools. LLMs cannot plan downstream actions or extract required fields for chaining (e.g., list_image_models returns model array, but structure of each model is not documented). This violates pattern:tool and mxe:include-chaining-ids.
No error handling or recovery guidance. Tools do not document what happens when API rate limits are hit, model is invalid, image format is unsupported, or API credentials expire. LLMs are given no actionable next steps (retry, fall back, ask user). Violates pattern:recovery-guide and pattern:error-classification.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 22 | - | v1 |
Get the currently selected image generation model.
List available image generation models from Google AI. This tool queries the Google AI API to retrieve a list of models that support image generation. Use this to discover which models are available for your API key.
Resize an image to specified dimensions or fit within maximum bounds. This tool resizes an image file, optionally constraining it to maximum width/height.
Set the model to use for image generation. This tool sets the active model for subsequent image generation requests. Use 'list_image_models' first to see available models.
Enum constraints missing for free-form string parameters. 'format' in convert_image, 'aspect_ratio' in generate_image/edit_image/generate_image_with_reference lack valid value enums (e.g., format: [png, jpeg, webp]). LLMs will hallucinate invalid values. Violates pattern:constrained-input.
Parameter relationships and dependencies not documented. set_image_model sets a stateful 'current model', but MCP is stateless per the 2026-07-28 spec. generate_image depends on prior set_image_model call (per description), but this is a hidden sequential dependency that violates stateless design. Should either (a) pass model directly to each tool, or (b) explain the state management in detail.
Missing parameter constraints and validation rules. max_width/max_height/width/height/quality lack documented ranges, defaults, and precedence. 'reference_paths' array has no maxItems constraint (description says 'up to 3' but schema does not enforce it). LLMs cannot reliably predict valid inputs.
Inconsistent parameter naming and types. Some parameters are nullable (type: [string, null]) for optional values, but others may omit null type when they should allow it. E.g., 'model' in generate_image is [string, null] (good), but quality and max_width/max_height lack clarity on null handling vs default behavior.
Tool descriptions lack LLM-optimized context. Descriptions are present but often generic (e.g., 'Resize an image to specified dimensions'). They do not explain WHEN to use each tool vs alternatives (generate vs generate_with_reference?), or hidden prerequisites (API key setup, model selection). Baseline for good descriptions is 50-200 chars with clear WHAT/WHEN/HOW structure. Current descriptions often miss the WHEN and HOW.
No permission or scope declarations. Tools that generate/edit images should document if they require specific API scopes or user permissions. Violates pattern:scope-declaration.