Loading ToolBench
FastMCP server exposing the Blacknode workflow toolkit to MCP clients. Enables building, validating, running, and exporting node-graph workflows with support for learned nodes, templates, and editor integration.
24 tools with mixed quality. Naming is generally verb-first and clear (list_*, get_*, create_*, add_*, etc.), following conventions well. Descriptions are present for all tools and range 40 - 180 chars, meeting the 10 - 1024 baseline. However, parameter descriptions are sparse or missing entirely in many tools. Input schemas are visible and typed, but lack depth in constraints (no enums, ranges, or format specs). Output schemas are undocumented, LLMs cannot predict return structure. Error handling is minimal; no recovery guidance. Tools like save_workflow, create_node_type, and delete_learned_node expose risky operations without confirmation patterns or dry-run support. Composition is reasonable (single responsibility mostly observed), but chaining is weak, responses don't consistently include IDs needed for downstream calls.
Add a node to a workflow and return the updated workflow plus validation.
Add a typed edge between two existing nodes; rejects incompatible types.
Cook (execute) a single node in the editor and return its output.
Create a permanent learned node type that executes in the Docker sandbox.
Create an empty workflow scaffold that already contains an Output node.
Delete a learned node from disk and unregister it; requires confirm=True.
Convert the workflow to a standalone Python script using blacknode.Graph.
Output schemas undocumented. LLMs cannot predict return structure for any of the 24 tools. Responses likely include verbose metadata, internal IDs, and unstructured fields that waste tokens and confuse downstream reasoning.
Destructive operations lack confirmation or dry-run patterns. delete_learned_node requires confirm=True flag, but save_workflow (overwrite=false default) and promote_learned_node (overwrite=false default) allow silent overwrites. No recovery guidance on failure.
Parameter descriptions are sparse or generic. Many parameters lack format specs, constraints, or examples. E.g., 'path' in load_workflow has no guidance on absolute vs relative, file extension, or error cases. 'code' in create_node_type lacks signature requirements.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Get the current graph loaded in the running Blacknode editor backend.
Get managed stream, persistent controller, and robot-driver status.
Return the Python source for a learned node.
Return input/output ports and defaults for one node type.
List learned nodes stored on disk.
List every Blacknode node type with category and port schema.
List recent run summaries from the running Blacknode editor backend.
List workflows saved in the running Blacknode editor backend.
List shipped workflow templates with their descriptions.
Load a shipped template workflow by slug, relative path, or absolute path.
Load a workflow JSON file from disk and return its dict form.
Promote a learned node into custom-nodes or community-nodes.
Execute the workflow; returns cooked value, run id, and event log.
Validate and save a workflow JSON file to disk.
Replace the graph in the running Blacknode editor backend.
Stop managed streams, controllers, and robot drivers in the editor.
Run full schema + port-type validation and return errors/warnings.
No input validation or error recovery guidance. Tools return errors but do not guide LLM on next steps. E.g., if run_workflow fails, no suggestion to call validate_workflow first. If load_workflow fails, no hint to call list_saved_workflows.
Response chaining incomplete. Tools like add_node, create_workflow, and run_workflow do not document whether they return node_id, workflow_id, or run_id, fields needed for downstream calls. Breaks tool composition.