Loading ToolBench
An MCP server that dynamically registers ComfyUI workflows as tools, enabling integration of ComfyUI image generation workflows with Claude and other MCP clients.
This server has critical definition quality gaps. The two tools lack proper schemas, descriptions are incomplete or vague, and parameter definitions are essentially absent. Tool 1 (list_available_workflows) has a reasonable description but empty input schema. Tool 2 (dynamic_workflow_tools) is dynamically registered with an incomplete description and no visible schema in the source code. The dynamic tool factory (src/factory.py) shows an attempt to build Pydantic models and function signatures via makefun, but the source is truncated and key schema definition code is cut off. Without seeing the complete schema generation in factory.py, I cannot verify that proper JSON Schema with types and descriptions is actually produced. The server relies heavily on runtime introspection and dynamic registration, making static schema validation impossible.
Dynamically registered tools created from ComfyUI workflows found in the workflows/ directory. Each tool is named after its workflow configuration and accepts parameters defined in the workflow's MCP_Config node.
Returns a list of all available workflows on this server. Use this to discover what you can do.
dynamic_workflow_tools has no visible input schema in source code. Factory code is truncated, preventing verification that proper JSON Schema with parameter types and descriptions is generated.
dynamic_workflow_tools description (37 chars) is too generic and fails to explain when/why an agent should call it vs list_available_workflows. Lacks clarity on what each dynamically registered tool does, what inputs it expects, what outputs it returns, or any prerequisites.
list_available_workflows input schema is empty ({}), indicating no parameters. However, the returned manifest is unstructured text (markdown string), not a structured JSON response. Agents must parse plaintext, wasting tokens and risking errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
No error handling guidance visible. If a workflow fails to execute (ComfyClient.queue_prompt, wait_for_execution), what happens? Stack traces are returned to the LLM unprocessed. No recovery hints like 'ComfyUI unreachable, check if service is running' or 'Timeout executing workflow, retry or check logs.'
WorkflowConfig parameters (name, type, description, required) are defined in models but the actual JSON Schema generation in factory.py is truncated. The code shows Pydantic Field usage and makefun function creation, but the critical section building the final MCP tool schema is cut off (annotation incomplete). Cannot verify that parameter descriptions are actually attached to the schema.
No output schema documented for dynamic_workflow_tools. What does a workflow execution return? Filenames? File contents? Status? URLs? The agent must guess.
ComfyUI client (src/comfy_client.py) hardcodes COMFY_URL = 'http://127.0.0.1:8188'. This assumes ComfyUI is always on localhost:8188. No configuration mechanism, no environment variable injection, no connection validation in tool description. If ComfyUI is remote or on a different port, the tool silently fails or requires code changes.
list_available_workflows returns plaintext markdown manifest, not structured JSON. Agents must parse text. If the manifest is large (many workflows), parsing wastes tokens. No pagination, no filtering, no structured field access.