Loading ToolBench
Model Context Protocol server for ComfyUI image generation and modification workflows.
The server provides 7 tools with mostly complete schemas and descriptions, but exhibits inconsistent quality across tools. All tools have descriptions (10-20+ word range), and input schemas are present with type definitions. However, several tools lack output schema documentation, parameter descriptions are sometimes vague, and error handling guidance is minimal. The naming convention is mostly clear (verb_noun pattern: generate_image, get_image, etc.), but some descriptions could better explain when/why to use each tool versus similar ones. The server follows basic MCP patterns but has gaps in error recovery guidance and missing output documentation.
Generate, modify, or post-process images using ComfyUI. Three modes (auto-detected): - txt2img: Provide prompt → generates image from text - img2img: Provide prompt + image_path → edits the reference image using Flux 2 Klein's native edit pattern (ReferenceLatent + CFGGuider), which preserves character/subject identity far better than classic denoise-based img2img. Best results at ~1MP references; 128×128 inputs will be upscaled before encoding. - post-process: Provide image_path without prompt → resize and/or remove background only By default, returns immediately with a prompt_id and status 'queued'. Use comfyui_get_image to poll for completion and retrieve image URLs. Set wait: true to block until the image is ready (or fails/times out) and get image URLs directly in the response. Parameters: - prompt (string, optional): Text description of desired image - negative_prompt (string, optional): What to avoid in the image - image_path (string, optional): Absolute path to input image (triggers img2img or post-process) - width/height (int, optional): Target output dimensions (triggers resize post-processing) - remove_background (boolean, optional): Remove background from output image - loras (array, optional, max 4): LoRA stack. Each entry: { name, strength_model (-2..2, default 1.0), strength_clip (optional, defaults to strength_model) }. Omit to fall back to COMFYUI_DEFAULT_LORAS env (if set). Pass [] to explicitly disable defaults. Use comfyui_list_loras to discover available names. - wait (boolean, optional, default false): Block until image is ready and return URLs directly Must provide at least prompt or image_path.
Retrieve image URLs for a previously queued job by prompt_id. Use this to poll for completion after calling comfyui_generate_image (default non-blocking mode). Returns status (pending/executing/completed/failed/not_found) and image URLs when ready.
List past image generation requests with current status.
Output schemas not documented for any tool. Tools return URLs, prompt_ids, or history entries but no schema is specified to guide LLM parsing of responses.
get_image, get_request_history, list_workflows, and remove_background lack description of what data they return (e.g., field names, structure). Descriptions focus on purpose but omit 'Returns X fields: ...' guidance.
No error handling guidance in descriptions. Tools do not document what happens on failure (e.g., 'if image not found, returns 404') or how to recover. No actionable error messages visible in code.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
List available LoRA files on the ComfyUI server (reads the LoraLoader node enum from /object_info). Returns { loras: string[] } of filenames you can pass to comfyui_generate_image via the `loras` parameter.
modify_image and resize_image accept local filesystem paths (image_path parameter) without sanitization guidance. No documentation of path traversal prevention or allowed directory constraints.
Parameter descriptions lack format/constraint details. E.g., width/height are 'numbers' but no min/max specified. denoise_strength is 0.0-1.0 but description doesn't explicitly enforce bounds. LLMs will pass arbitrary values.
get_image description does not explain what URLs it returns or how they are constructed. LLM must infer that URLs can be used to fetch images from the embedded HTTP server.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. generate_image, modify_image, resize_image, and remove_background are destructive/stateful but lack annotation.
generate_image, modify_image, resize_image, remove_background are all asynchronous (return prompt_id for later retrieval) but descriptions do not clarify this workflow or suggest calling get_image next.