Loading ToolBench
A Model Context Protocol server for InvokeAI image generation
This server has explicit tool definitions with partial schema coverage, but significant gaps in descriptions, parameter validation, and output documentation. All 4 tools are registered with names and basic descriptions, but lack the depth and rigor expected for production agents. Tool descriptions average ~80 characters (vs. baseline 194 chars), and many parameters lack descriptions or type constraints. No tool clearly documents its output schema or error handling paths. The server defines tools for image generation (text2img, img2img) and model discovery (list_models, get_model_info), but the implementation does not enforce parameter constraints (e.g., width/height must be multiples of 8, cfg_scale ranges, seed bounds) at the tool definition level. No evidence of idempotency documentation, confirmation patterns for destructive operations, or recovery guidance in error messages.
Get detailed information about a specific model
Generate an image using text prompt and an input image as reference
List available models on the connected InvokeAI instance
Generate an image from a text prompt using InvokeAI
Tool descriptions are too brief (30 - 50 chars vs. baseline 194 chars). 'Generate an image from a text prompt using InvokeAI' does not explain WHEN to use text2img vs img2img, what the output looks like, or what prerequisites exist (e.g., InvokeAI server must be running). LLMs cannot reliably select between similar tools without richer context.
Output schemas are not documented anywhere in tool definitions or source code. Agents cannot predict what text2img returns (e.g., image URL? Base64? File path? Metadata?). The enqueue_graph and wait_for_completion functions return dict structures, but the MCP tool schemas lack 'returns' or 'output' field descriptions. This violates pattern:tool and forces LLMs to guess.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 23 | - | v1 |
Parameter descriptions are missing or incomplete. E.g., scheduler param has description 'Noise scheduler (e.g., 'euler', 'heun', 'lms')' but no enum constraint or list of valid values; model_key is 'Model identifier (e.g., 'sd-1-5-pruned')' with example instead of constraint; width/height descriptions say 'must be multiple of 8' but this is not enforced as a schema constraint (pattern, minumum, multipleOf). LLMs cannot parse prose constraints reliably.
No error handling guidance. The source code shows TimeoutError, RuntimeError, and ValueError exceptions, but tool definitions do not document what errors can occur or how to recover. E.g., if text2img times out after 300s, what should the LLM do? Retry? Reduce steps? Use a different model? No recovery path is defined.
No confirmation or dry-run pattern for image generation tools. text2img and img2img are potentially long-running, resource-intensive operations (may take seconds to minutes and consume GPU memory). An LLM could accidentally trigger expensive generations without explicit user confirmation. Pattern:confirmation-request should apply.
Parameter types are present in schemas but lack bounds. width, height, steps, cfg_scale, lora_weight, denoising_strength have no minimum/maximum constraints in the schema. Agents could pass absurd values: width=1000000, steps=10000, cfg_scale=999. These would cause API errors or hang the server. Baselines show numeric params should declare min/max.
model_type parameter for list_models has no enum or documentation of valid values. Description says 'Type of models to list (main, controlnet, lora, vae, etc.)' with examples instead of a formal constraint. An LLM might pass 'model_type=embeds' or 'model_type=invalid' and get a cryptic API error.
No documented relationship between text2img parameters and expected behavior. When should an LLM use cfg_scale=7.5 vs 15? What does negative_prompt do exactly? These parameters are AI/ML-specific and require domain knowledge. Descriptions should include guidance on typical values and trade-offs (e.g., 'Higher cfg_scale (7-15) follows the prompt more strictly; lower values (5-7) are more creative but may diverge from intent').
list_models and get_model_info return structures are not documented. Agents cannot know whether to expect {models: [{key, name, type, ...}, ...]}, or a flat list, or nested objects. Return type documentation is critical for tool chaining (e.g., after list_models, can the LLM pass the returned model_key directly to text2img? It can, but this is not explicit).
image_path parameter in img2img has no validation guidance. Can it be a relative path, absolute path, or URL? What formats are accepted (PNG, JPEG, WebP)? If the file is missing, the code raises ValueError('Image file not found: {image_path}'), but the tool description does not warn the LLM that this can fail. This violates pattern:recovery-guide.