MCP Debugger vs N8n MCP — MCP Server Comparison | AllMCPs
Side-by-Side Model Context Protocol Comparison
MCP Debugger vs N8n MCP
In-depth architectural comparison of the MCP Debugger and N8n MCP MCP servers. Compare execution transports, security boundaries, tool capabilities, quality scores, and ready-to-paste client installation snippets for Claude, Cursor, Windsurf, and VS Code.
At a Glance & Executive Verdict
MCP Debugger
Developer Tools · Local stdio
Quality: 48/100 (Fair) | Auth: No auth required
N8n MCP
Developer Tools · Local stdio
Quality: 60/100 (Good) | Auth: No auth required
Verdict Summary: Choose MCP Debugger if you need specialized Developer Tools tools running via a local process. Choose N8n MCP if your workspace requires Developer Tools integration with local subprocess execution. Both servers can be configured concurrently in your client's mcpServers manifest.
Which MCP Server Should You Choose?
M
Choose MCP Debugger when:
You need dedicated capabilities in the Developer Tools domain.
You prefer local stdio subprocess transport architecture.
Your security boundary fits: No auth required (Free / Open Source).
Primary tools included: DAP-based debugging across ten language environments, Launch and remote-attach workflows, Content- and function-addressed breakpoints.
You need dedicated capabilities in the Developer Tools domain.
You prefer local stdio subprocess transport architecture.
Your security boundary fits: No auth required (Free / Open Source).
You have access to required keys: N8N_API_URL, N8N_API_KEY, N8N_MCP_READ_ONLY, N8N_MCP_DISABLED_TOOLS, N8N_MCP_ALLOWED_WORKFLOW_IDS, N8N_MCP_ALLOWED_TAGS.
MCP Debugger is categorized under Developer Tools and uses a local stdio subprocess. In contrast, N8n MCP belongs to Developer Tools using local stdio subprocess. Select MCP Debugger when you need capabilities focused on developer tools and N8n MCP when you require tools for developer tools.
Scaffold a TypeScript skeleton for an n8n custom node from a plain-English description. Returns a single TypeScript file implementing INodeType with description, credentials reference, and an execute method stub. Pure code generation — no network, no filesystem writes.
workflow_generate
Generate a valid n8n workflow JSON from a plain-English description. Handles webhook/schedule/RSS triggers, common action nodes (Slack, Google Sheets, Discord, Gmail, Notion, HTTP), and AI Agent setups (LangChain root agent + chat model + memory + optional HTTP tool, wired with ai_languageModel / ai_memory / ai_tool connections). Returns workflow JSON with unique node IDs, connections, positions, and typeVersion on every node. Output is non-deterministic (random node IDs and webhook paths).
workflow_lint
Lint an n8n workflow JSON. Returns concrete errors and warnings: missing credentials, deprecated node types (Function -> Code, spreadsheetFile -> convertToFile/extractFromFile), broken connections, missing or non-numeric typeVersion, duplicate node names or IDs, AI Agent missing ai_languageModel sub-node, Webhook missing webhookId, IF node still on v1 condition schema, rate-sensitive nodes without retries, Code-node sandbox violations, expression staleness (`$('NodeName')` referencing missing nodes), manualTrigger in active workflows, disabled-but-wired nodes, empty Set nodes, HTTP method/body mismatches, Schedule trigger DST risk, credential drift, webhook test paths in active workflows. Deterministic, rule-based.
workflow_diff
Semantic diff between two workflows. Reports nodes added / removed / modified (with field-level deltas: type, typeVersion, parameters, credentials, disabled, position), connection topology changes, and settings drift. Ignores noise (small position deltas, createdAt/updatedAt). Pair with workflow_get to compare deployed vs local. Deterministic.
execution_explain
Diagnose a failed or surprising n8n execution. Paste the execution JSON (from the n8n UI 'Show details' or `GET /executions/:id?includeData=true`); returns a per-node summary highlighting nodes that returned 0 items, unresolved `={{ ... }}` expressions, errors with hints, and LLM token usage. Hits the most common debugging pain point: items 'silently disappearing' between nodes. Deterministic, rule-based.
execution_replay
Build a self-contained replay workflow that exercises a single node from a larger workflow. The replay workflow is Manual Trigger -> Replay Seed (Code node with pinned items) -> target node. Optional `inputItems` or an `execution` payload pins what the target sees. Useful for iterating on one stubborn node without re-running the whole pipeline. Returns workflow JSON ready to import or push via workflow_create.
execution_timeline
Render an n8n execution as a per-node timeline: start offset, duration, items in/out, error flag. Complements execution_explain — that one surfaces *why*, this surfaces *when*. Output is a markdown table sorted by start time. Deterministic.
workflow_list
List workflows from a live n8n instance (requires N8N_API_URL + N8N_API_KEY env vars). Returns id, name, active, nodeCount, updatedAt, tags. Filter by active, tags, name. Use this when the user asks 'what workflows do I have?' or before workflow_get.
workflow_get
Fetch a single workflow JSON by id from a live n8n instance (requires N8N_API_URL + N8N_API_KEY). Returns the full nodes/connections payload — pair with workflow_lint to audit a deployed workflow.
workflow_create
Create a workflow on a live n8n instance (requires N8N_API_URL + N8N_API_KEY). Strips read-only fields (id, active, createdAt, ...) before posting. Workflows are created inactive — call workflow_activate afterward. Pairs with workflow_generate for end-to-end 'describe -> deploy'.
workflow_activate
Activate or deactivate a workflow on a live n8n instance (requires N8N_API_URL + N8N_API_KEY). Pass `active: false` to deactivate. Idempotent — re-activating an already-active workflow is a no-op on n8n's side.
execution_list
List recent executions from a live n8n instance (requires N8N_API_URL + N8N_API_KEY). Filter by workflowId, status (success|error|waiting), limit. Pass `includeData: true` to get the full execution body (large) — pair with execution_explain to diagnose a specific failure.