Loading ToolBench
Specialized MCP server for n8n workflow monitoring with KPI analysis
The server defines 3 tools with complete input schemas and reasonable descriptions. However, there are notable gaps: (1) All tools lack parameter-level descriptions, e.g., 'limit' and 'workflowId' have descriptions in schema, but the rubric requires EVERY parameter to have a clear, actionable description for LLM reasoning. (2) No output schemas are documented, LLMs cannot plan downstream usage without knowing what fields to expect. (3) Tool descriptions are moderate length (168 - 347 chars) but lack clarity on WHEN to use each tool instead of alternatives, and do not specify what data structure is returned. (4) No error handling guidance, if a workflow ID is invalid or n8n API is unreachable, the generic error message provides no recovery path. (5) Security: API credentials are injected via environment variables (correct), but no mention of rate limits, permission checks, or audit trails. (6) The tools are narrowly scoped to monitoring (read-only, good), but lack composition hints, e.g., if you list active workflows, the IDs should directly feed into execution queries.
List all active workflows in the n8n instance. Returns workflow ID, name, creation date, and update date.
Get detailed information about failed workflow executions, including error messages, error descriptions, and last executed node. Helps diagnose workflow failures. Optionally filter by workflow ID or limit results.
Get workflow execution history with comprehensive KPI analysis. Returns execution summary, failure rate, execution modes distribution, per-workflow metrics, timing analysis, recent failures, and alerts. Optionally filter by workflow ID or limit results.
No output schemas documented. LLMs cannot plan tool chaining or extract required downstream IDs (e.g., workflow_id from list, execution_id from history) without seeing the response structure.
Parameter descriptions exist in schema but lack actionable guidance. 'limit' and 'workflowId' are named but don't explain the filtering behavior, default fallback, or interdependencies. E.g., 'limit: Maximum number of executions to retrieve (default: 100)', missing explanation of pagination, whether limit is per-workflow, or how to iterate large result sets.
Tool descriptions do not distinguish when to use each tool. All three are monitoring-related; an LLM could conflate 'n8n_get_workflow_executions' (history + KPI analysis) with 'n8n_get_execution_details' (failed executions only). Add explicit guidance: 'Use this for..., not for...'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Error handling provides no recovery guidance. Code catches errors and returns generic error messages (e.g., 'Error: workflow not found'). Missing: error categorization (retryable vs user-fixable), suggestion of alternative tools, or helpful hints (e.g., 'Try n8n_get_active_workflows to list valid workflow IDs').
No pagination support documented. The 'limit' parameter caps results, but there is no cursor, offset, or next_page token to iterate large result sets. LLMs cannot fetch 'the next 100 executions' without explicit pagination guidance.
Tool naming is clear and action-oriented (get_*), but parameter naming lacks type suffixes. 'workflowId' is opaque, should clarify if it's a system ID string, numeric ID, or name. Rubric requires 'user_id', 'user_name', 'user_email' suffixes to disambiguate. Here, should consider 'workflow_id' (system ID) vs 'workflow_name' (human-readable).
No mention of rate limits, timeouts, or permission gates. If n8n API is slow or the agent is rate-limited, no guidance on retry strategy or backoff. Security pattern missing: no audit trail or permission checks documented.