Loading ToolBench
MCP server that bridges N8N workflows to the Model Context Protocol, enabling dynamic MCP tool generation from N8N workflows with credential management and workflow execution
N8N2MCP exhibits significant quality gaps across naming, descriptions, and schema completeness. While tool names generally follow verb_noun conventions (parse_workflow, validate_workflow, register_mcp), descriptions are inconsistent, some are adequate (parse_workflow: 72 chars), but others are extremely terse (health_check: 27 chars, list_mcps: 29 chars). Input schemas are partially visible but lack complete type information and per-parameter descriptions in most cases. Critical security issue: register_mcp accepts 'user_apikey' and 'secrets' as bare parameters, violating secret-injection patterns. Output schemas are not documented anywhere in the provided code. Error handling is absent, no recovery guidance, no error categorization. The server reads as a proof-of-concept rather than a production-grade tool collection.
Fetch workflow required credentials from N8N instance
Simple health check endpoint
Import N8N workflow template from their public API
Lists all registered MCPs
Parse N8N workflow JSON and return credential form configuration
Parse N8N workflow from uploaded file
Register an MCP configuration that will be built on-demand for each request
Secrets exposed as tool parameters: register_mcp accepts 'user_apikey' and 'secrets' array directly as parameters. These will be logged in MCP traces and agent histories, violating secret-injection patterns. Credentials must use server-side injection via environment or vault.
Output schemas not documented: No tool describes what fields or structure it returns. LLMs cannot plan downstream calls or extract required data (e.g., workflow IDs for chaining). All tools need explicit return type documentation.
Missing parameter descriptions in input schemas: Tools like register_mcp define parameters (user_apikey, secrets, code, workflow_id) but lack per-parameter descriptions. LLMs cannot infer what 'code' means (Python? JavaScript? MCP definition?) or what 'secrets' structure should be.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Remove an MCP registration and its credential mapping
Validate N8N workflow JSON structure
Trivial tool descriptions: health_check (27 chars), list_mcps (29 chars). These are below the 50-char baseline and provide almost no context for LLM tool selection. Expand to at least 50-100 chars explaining what data is returned and when to call.
No error handling guidance: No tool documents recovery steps, error categories (retryable vs fatal), or what to do if a call fails. For example, if validate_workflow detects invalid JSON, does the LLM retry or ask the user to fix the input? Undefined.
register_mcp requires manual workflow_id lookup: To register an MCP, the user/agent must know the workflow_id upfront. No tool accepts a human-readable workflow name and resolves it to an ID. This violates natural-identifiers pattern and forces extra discovery calls.
No pagination or result limiting documented: list_mcps returns an array but doesn't specify if it's paginated, capped, or unbounded. If 1000+ MCPs exist, returning all of them wastes context tokens and breaks LLM reasoning.
Destructive operation without confirmation: remove_mcp is marked destructive but has no dry-run or confirmation step. An LLM mistake could delete MCPs and their credential mappings irreversibly. Add a confirmation_required pattern or dry_run parameter.