Loading ToolBench
Visual creative expert plugin — search inspiration, enhance prompts, and generate AI images with intelligent workflow orchestration
The MeiGen AI Design MCP server provides 8 tools with varying quality. Most tools have reasonable descriptions (averaging 120-180 chars) and input schemas with type definitions and enums where appropriate. However, there are significant gaps: output schemas are not documented in the source code provided, parameter descriptions lack specificity about formats and ranges, error handling is not evident, and several tools conflate multiple concerns. The server follows basic naming conventions (verb-noun patterns like 'enhance_prompt', 'search_gallery') but some names are ambiguous ('manage_preferences' bundles 4 distinct actions). Tool definitions appear to be registered explicitly in src/server.ts, confirming they exist in the codebase.
Manage ComfyUI workflows: list, view, modify parameters, delete, and prepare workflows for local GPU-based image generation
Enhance and expand user prompts with creative details, visual logic, and style specifications for better AI image generation output
Generate AI images from prompts using configured providers (MeiGen, OpenAI, or ComfyUI) with support for aspect ratios, models, and reference images
Get random curated prompts and gallery suggestions for creative inspiration by category or completely random
List available image generation models from configured providers with their specifications and credit costs
Get, set, or update user preferences for default generation parameters, favorite prompts, and style notes
Search the MeiGen gallery and curated prompt library for inspiration by keyword or category
manage_preferences bundles 4 distinct actions (get, set, add_favorite, remove_favorite) into one tool, violating the single-responsibility principle. This should be split into separate tools (get_preferences, set_preferences, add_favorite_prompt, remove_favorite_prompt) so the LLM can invoke them independently and compose workflows more flexibly.
No output schemas documented in source code. The tool descriptions specify what tools return (e.g., 'list available models', 'return random curated prompts') but do not provide JSON schema definitions of response structures. LLMs cannot plan downstream tool calls or extract required fields without documented output schemas. Required fields like image URLs, model IDs, and gallery entries must be explicitly defined.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Compress and upload a local reference image to R2 cloud storage for use as referenceImages in generate_image
Parameter descriptions lack specificity about formats, ranges, and constraints. For example, 'aspectRatio' accepts strings like '1:1', '16:9', '9:16' but the description does not define the regex pattern or list all valid values. 'quantity' (number of images to generate) says '1-4' in description but no numeric min/max constraints are visible. 'limit' parameters do not specify maximum allowable values. LLMs infer constraints from descriptions when schema validation is absent, so these must be explicit and precise.
generate_image tool accepts 'referenceImages' as an array of URLs and says '(gpt-image-1.5 and ComfyUI only, not DALL-E)' but this constraint is buried in the description, not enforced via conditional logic or documented as a provider-dependent field. If the LLM calls generate_image with provider='openai' and referenceImages, the tool will silently fail or ignore the parameter. This should be validated and return a clear error: 'Reference images are not supported with provider: openai. Use provider: meigen or comfyui.'
No evidence of error handling or recovery guidance in the tool definitions. The server instructions mention 'If generate_image returns "No image generation providers configured"' but no tool shows how it communicates this error to the LLM, what status code it returns, or what the LLM should do next (e.g., 'Call setup_provider(provider=meigen) with an API token'). Error responses must tell the agent what to do next.
comfyui_workflow tool conflates multiple actions ('list', 'view', 'modify', 'delete') into a single tool with an 'action' enum parameter. This is harder for LLMs to use than separate tools like list_workflows, view_workflow, modify_workflow, delete_workflow. Each action has a different set of required parameters (e.g., 'modify' needs nodeId+input+value, but 'list' needs none), making conditional logic complex.
Parameter naming inconsistencies reduce clarity. 'query' (in search_gallery) vs 'prompt' (in enhance_prompt) for text input. 'provider' enum accepts 'meigen', 'openai', 'comfyui' but generate_image description says 'uses default by priority: meigen > comfyui > openai', the priority order should be explicit in all tools that use providers, not buried in descriptions.
get_inspiration description says 'Get random curated prompts and gallery suggestions for creative inspiration' but does not explain when to call this vs search_gallery. Are search_gallery results different from get_inspiration results? The description should clarify: 'Returns hand-curated suggestions by category (unlike search_gallery, which searches user-indexed prompts). Useful when the user is open to any idea.'
upload_reference_image description says it 'Compresses and uploads a local reference image to R2 cloud storage' but does not document what the tool returns. Does it return a URL? A file ID? The response schema must be explicit so downstream generate_image calls can use the uploaded image.