Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server has 3 well-defined tools with complete JSON Schema input definitions and descriptive text. Tool names follow verb_noun conventions (generate_image, edit_image, get_model_capabilities). However, there are several quality gaps: (1) descriptions lack actionable guidance for LLM selection (when to use one tool vs another), (2) parameter descriptions are present but some lack context about dependencies and constraints, (3) output schemas are NOT documented, critical for agent planning, (4) error handling and recovery guidance is minimal in tool descriptions. The server uses fastmcp with proper tool registration and includes tool annotations (readOnlyHint), which is a strong signal. However, the missing output schema documentation and thin descriptions around state modification (generate_image/edit_image both have WRITE risk but don't describe retry behavior or idempotence) pull the score into the 'fair' range.
Tools (3)
edit_imagewriteauthsource verified73/100
Edit an image with a prompt and optional mask.
generate_imagewriteauthsource verified76/100
Generate image(s) from a prompt.
Parameters are provider/model-agnostic. Engines normalize to native knobs.
Output schemas are not documented for any tool. LLMs cannot plan downstream calls or extract required fields (image URLs, capability lists, etc.) without knowing what the response contains.
Tool descriptions do not explain write side effects or idempotence guarantees. 'generate_image' and 'edit_image' write to disk but do not state: (1) is the operation idempotent? (2) is it safe to retry? (3) what happens if the directory does not exist? (4) what happens on partial failure (e.g., 5 of 10 images fail)?
Parameter dependencies are undocumented. The 'size', 'orientation', 'quality' parameters all have provider-specific support, which providers honor which parameters? The 'negative_prompt' description says 'honored by supporting providers' but does not list which ones.
generate_imageedit_image
Recommendations
Add an explicit 'Output' section to each tool description documenting the response schema: e.g., 'Returns an object with: { images: [{ url: string, size: string, format: string }], metadata: { provider: string, model: string, elapsed_ms: number } }'.
Clarify write semantics: 'generate_image writes generated images to disk at the specified directory or temp directory. The operation is idempotent for the same (prompt, seed) pair. Partial failures (e.g., 3 of 5 images fail) return the successful images and an error message listing failed indices.'
Document provider-capability matrix: 'Provider support: openai (all params), gemini (negative_prompt, background), vertex (all params), azure (size, orientation), openrouter (varies by model). Use get_model_capabilities to discover current provider support.'
Expand tool descriptions with decision guidance: 'Use generate_image to create new images from scratch. Use edit_image to modify existing images (inpainting, variations). If you have an image and want to apply a textual edit, prefer edit_image.'
Add error recovery guidance: 'Common errors: ToolError with 'Unsupported provider' → call get_model_capabilities() to check enabled providers; 'Invalid size for provider' → retry with a different size value; 'API rate limit exceeded' → retry after 60 seconds with exponential backoff.'
Error handling and recovery guidance is minimal. Tool descriptions do not explain: (1) what errors are retryable (rate limits, timeouts)? (2) what errors are user-fixable (invalid provider, bad API key)? (3) what errors are fatal (unsupported model)?
Tool descriptions lack context for disambiguation. When should an agent call 'generate_image' vs 'edit_image'? The descriptions do not explain the distinction or trade-offs.
Enum parameter values are not self-documenting. Size codes 'S', 'M', 'L' do not map to pixel dimensions or aspect ratios in the description. Quality 'draft', 'standard', 'high' should note cost/latency implications.
generate_imageedit_image
Add parameter interdependency notes: 'If negative_prompt is specified but provider does not support it, the parameter will be silently ignored. Check get_model_capabilities for per-provider feature support.'
Document the 'images' parameter encoding more precisely in edit_image: 'Supported encodings: (1) https://... URL (server will download), (2) file:///path/to/image.png (server will read), (3) data:image/png;base64,... (recommended for reliability), (4) bare base64 (wrapped as data URL internally). For best results, use data URL or base64.'
Add a batch/count note: 'To generate multiple distinct images, call generate_image once with n > 1. To generate variations of an existing image, use edit_image with the same images array and n > 1.'
Document result limits: 'Maximum n is provider-dependent (openai: 10, gemini: 8, vertex: varies). If n exceeds provider limit, the tool will reject the call with a specific error message.'.