Loading ToolBench
The server defines 19 tools with consistent naming conventions (verb_noun pattern), explicit input schemas with proper JSON Schema structure, and descriptions for all tools. However, there are significant gaps in parameter descriptions, output schema documentation, and error handling guidance. Most tools lack actionable error recovery information and descriptions of return structures. Parameter validation constraints are minimal, and several parameter descriptions are generic or missing depth. The definitions would benefit from richer parameter constraints (enums, patterns, length limits) and explicit output schema documentation for each tool.
Activate a workflow
Create a new tag
Create a new n8n workflow from JSON definition
Deactivate a workflow
Delete an execution
Delete a tag
Delete a workflow
Output schemas not documented. No tool includes a documented return type, expected fields, or response structure. LLMs cannot plan downstream calls or extract chaining IDs without knowing what fields to expect.
Complex parameters lack proper constraints. 'nodes' and 'connections' in create_workflow/update_workflow accept untyped arrays/objects with only generic descriptions ('Array of workflow nodes'). These should have JSON schema definitions showing required fields, types, and nested structure, or at minimum a format description (e.g., 'n8n node JSON schema format').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Execute a workflow with optional input data
List available credentials (names only, no sensitive data)
Get details of a specific execution
Get workflow execution history with filtering options
List all available tags
Get detailed information about a specific workflow
Get webhook URLs for a workflow
List all n8n workflows with optional filtering
Retry a failed execution
Search workflows by name or tags
Update a tag
Update an existing workflow
No error handling guidance. Tools lack descriptions of failure modes, what could go wrong, and how the agent should recover. E.g., delete_workflow should note 'Returns an error if the workflow is currently executing' and suggest checking get_executions first.
Parameter descriptions are generic or missing critical context. E.g., 'data' in execute_workflow says 'Input data for the workflow execution' but does not explain the expected structure, format, or how it maps to workflow variables.
No idempotency or state-mutation clarity. Tools like execute_workflow and retry_execution do not clarify whether they are idempotent. Agents retry on ambiguous failures, if retry_execution is not idempotent, it could trigger duplicate executions.
Numeric parameters lack bounds. 'limit' in list_workflows and get_executions default to 10 but have no min/max constraints. Without bounds, an LLM could request limit=100000, overwhelming the API or context window.
Pagination cursors underdocumented. Tools returning paginated results accept 'cursor' but do not explain its format, how to obtain the first cursor, or what a null/missing cursor means.
Tool descriptions lack dependency hints. Users often want to 'search for a workflow by name', search_workflows exists but is not mentioned in list_workflows description. Agents may not discover it without explicit cross-references.