n8n-ops-mcp is an ops-focused MCP server that connects AI clients to a live n8n instance for workflow management, monitoring, and auditing.
Read-Only Capabilities (always available)
List & inspect workflows — filter by name, tags, active state; fetch full node graphs
Browse & search executions — list recent runs by status, fetch per-node logs, text-search error payloads (e.g. ECONNREFUSED)
Execution statistics — per-workflow failure rates, avg/p95 runtimes, last failure/success timestamps
View webhooks — enumerate webhook and form-trigger URLs with fully-formed trigger URLs
List schedules — surface all schedule triggers with human-readable descriptions
Validate workflows — static analysis for deprecated nodes, legacy Code-node API usage, orphan/disabled nodes, missing triggers
Diff workflows — semantic comparison vs. a snapshot file or inline object, with field-level paths for added/removed/modified nodes
Security audit — run n8n's built-in audit across credentials, database, nodes, filesystem, and instance settings
Find workflows by node type or credential — blast-radius scanning before rotating or deleting credentials
Check disabled nodes — surface drift signals not visible in the n8n UI
Tag management (read) — list all tags and read tags on a specific workflow
Credential metadata — list names, types, timestamps (secrets never returned); fetch credential JSON schemas
Audit browser-bridge usage — find every workflow calling the browser-bridge CLI
Write Capabilities (require N8N_ENABLE_EDIT=true)
Trigger workflows — via webhook path or workflow ID (confirm-gated)
Create, save, archive, unarchive, delete workflows — with auto-backup, dry-run preview, and validation before destructive changes
Activate/deactivate workflows — enable or disable triggers
Cancel, retry, or delete executions — single or batch (up to 50 at once), with bounded concurrency
Pin/unpin node data — pin sample data to nodes for testing without re-running upstream nodes
Tag management (write) — create, delete, and set workflow tag sets
Credential Write Capabilities (require both N8N_ENABLE_EDIT=true AND N8N_ENABLE_CREDENTIALS_WRITE=true)
Create credentials — with secret data; secrets are never echoed in responses
Delete credentials — permanent deletion (cascades to all referencing workflows)
Provides ops-focused tools for n8n, allowing listing, inspecting, triggering, validating, managing tags, running security audits, and safely editing n8n workflows with auto-backup and confirm gates on destructive writes.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@n8n-ops-mcp list all workflows with tag 'critical'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
n8nctrl is an operator control CLI for n8n workflow automation. It lists, inspects, validates, audits, and reports on your n8n workflows and executions over the n8n Public API, so you can ask "what broke in my n8n today?" and act on the answer from a terminal, cron, CI, or an agent. Unlike catalog/docs tools that index n8n's node library for building flows, n8nctrl is built for operating the flows you already run: triage failed executions, find drift, scan for security risks, and inspect live schedules, webhooks, credentials metadata, and tags.
The MCP surface is the adapter layer: run n8nctrl mcp for stdio MCP, or keep using the back-compat n8n-ops-mcp binary in existing launchers. The same package also ships a first-class OpenClaw plugin. It works with Claude Desktop, Claude Code, Codex CLI, Cursor, Windsurf, or any other MCP host, with no hard dependency on a specific model or agent harness.
n8nctrl connects operators and agents to a running n8n instance for workflow automation ops: it surfaces your n8n workflows, executions, schedules, webhooks, tags, and credentials over the n8n Public API. From the CLI, you get scriptable read/report commands for shells, cron, and CI. Through n8nctrl mcp or the compatibility n8n-ops-mcp bin, your agent gets native awareness of your n8n footprint, so it can answer "what's broken in my n8n?", trigger a workflow from chat, audit for security risks, or clean up old executions without leaving your client.
Read tools are always available. Write tools (create, save, archive, delete, trigger, retry, tag CRUD, pin data) are hidden unless N8N_ENABLE_EDIT=true, and credential writes sit behind a second gate. Destructive operations are confirm-gated and snapshot to a backup directory first. See the Security model.
Related MCP server: n8n Architect MCP Server
npm install -g n8n-ops-mcpThe npm package name remains n8n-ops-mcp for compatibility. After a global install, use the standard CLI as n8nctrl. Existing n8n-ops and n8n-ops-mcp launchers remain supported as compatibility aliases.
For MCP launchers, you can still run it on demand via npx -y n8n-ops-mcp (no global install needed), which is what the MCP client config below does.
Drop this into your MCP client config (Claude Desktop shown). The binary runs straight from npm via npx, so there is nothing to install first:
{
"mcpServers": {
"n8n": {
"command": "npx",
"args": ["-y", "n8n-ops-mcp"],
"env": {
"N8N_BASE_URL": "https://n8n.example.com",
"N8N_API_KEY": "your-n8n-api-key"
}
}
}
}Generate the API key in n8n under Settings → API. Point N8N_BASE_URL at your n8n instance. That is the whole read-only setup. To unlock write tools, add "N8N_ENABLE_EDIT": "true" to env.
Then ask your agent:
What n8n workflows broke today?
It calls n8n_list_executions with status=error, then n8n_get_execution on the failing run for the per-node log and raw error.
Generated from docs/assets/workflows/n8n-ops-loop.json with lidless workflow.
40 tools across read-only ops, the workflow + execution lifecycle, tags, and credentials. Write tools (marked) are hidden unless N8N_ENABLE_EDIT=true; credential writes (marked ✓✓) need a second gate.
Tool | Purpose | Write |
| List workflows, filter by | |
| Fetch one workflow, optionally with full node graph | |
| List recent executions, filter by workflow / status | |
| Fetch an execution with per-node run log + raw error | |
| Text-search recent executions for an error fragment | |
| Enumerate webhook + form-trigger URLs | |
| Static checks: deprecated nodes, legacy Code-node API, orphans | |
| Compare a workflow against a snapshot file or inline object - semantic diff (added/removed/modified nodes with field paths) | |
| List every schedule trigger across workflows with human-readable descriptions ("daily at 03:00", "cron: 0 */6 * * *") | |
| Find every workflow that calls the | |
| Generate a ready-to-paste n8n node that calls a | |
| Run n8n's built-in security audit (credentials, database, nodes, filesystem, instance) | |
| Find every workflow using a given node type (e.g. | |
| Per-workflow stats over a recent window: counts, failure rate, avg + p95 runtime, last failure | |
| List workflow tags with | |
| Read the tags currently attached to a workflow | |
| List credentials (metadata only - secrets never echoed; admin/owner key required) | |
| Fetch the JSON schema for a credential type (e.g. | |
| Find every workflow node that references a credential by | |
| Scan workflows for | |
| Run a workflow via webhook (reliable) or workflow-id (confirm-gated; executes arbitrary workflow nodes) | ✓ |
| Create a workflow (confirm-gated for writes; dry-run preview without confirm; accepts | ✓ |
| Enable a workflow's triggers (confirm-gated; arms arbitrary-code execution) | ✓ |
| Disable a workflow's triggers (confirm-gated) | ✓ |
| Overwrite a workflow with auto-backup + validation + confirm gate | ✓ |
| Soft-delete a workflow (confirm-gated; reversible; preserves id) | ✓ |
| Restore an archived workflow (confirm-gated; does NOT reactivate) | ✓ |
| Permanently delete a workflow (confirm-gated, snapshot-before-delete, restore via | ✓ |
| Stop a running or waiting execution by id (confirm-gated) | ✓ |
| Retry a failed execution by id (confirm-gated; returns a new execution) | ✓ |
| Permanently delete an execution record (confirm-gated, irreversible) | ✓ |
| Batch form of delete (client-side fan-out, confirm-gated, irreversible, max 50 ids) | ✓ |
| Pin sample data to a node so downstream nodes use it during testing (confirm-gated, replace-or-merge) | ✓ |
| Clear pinned data on one node or the whole workflow (confirm-gated, idempotent) | ✓ |
| Create a workflow tag (confirm-gated; reversible via | ✓ |
| Permanently delete a tag (confirm-gated; cascades - removes the tag from every workflow) | ✓ |
| Replace the tag set on a workflow (confirm-gated; reversible by re-setting) | ✓ |
| Batch retry executions (confirm-gated, max 50 ids, AbortController on 5xx) | ✓ |
| Create a credential (confirm-gated; double-gated behind | ✓✓ |
| Permanently delete a credential (confirm-gated; double-gated; cascades - every workflow referencing it will fail) | ✓✓ |
Write tools are hidden unless N8N_ENABLE_EDIT=true.
n8n_list_workflows - filter by active, tags, name (substring), limit. Returns id, name, active state, tags, updatedAt.
n8n_get_workflow - fetch one by id. Returns metadata by default. Pass includeDefinition: true for the full node graph + connections.
n8n_list_executions - filter by workflowId, status (success/error/running/waiting/canceled), limit. Returns id, workflowId, workflowName, status, mode, startedAt, stoppedAt.
n8n_get_execution - includes per-node run log (truncated to maxExecutionLogBytes, default 64 KB) and the raw error object verbatim when status is error. Pass includeRunData: false to skip the run log.
n8n_search_executions - defaults to scanning status=error executions for a query fragment (e.g. ECONNREFUSED) and returning matches with workflow context + a snippet around each hit. scope: "error" (default) greps the error payload only; scope: "all" also greps full per-node run data (slower, may return node outputs - treat snippets as sensitive). Optional workflowId, status, limit (default 50, max 250), maxMatches (default 20), snippetChars (default 160). Returns matches plus a skipped array for any execution that failed to fetch.
n8n_list_webhooks - scans workflows for webhook and form-trigger nodes and returns their paths + fully-formed triggerUrl. Pairs with n8n_trigger mode='webhook'. Optional workflowId, activeOnly (default true), limit (default 50).
n8n_validate_workflow - checks for deprecated node types (function → code), legacy Code-node API ($node[], items global, require()), orphan nodes, disabled nodes, missing trigger. Returns issues with severity (error/warning/info) plus a summary count.
n8n_list_schedules - scans n8n-nodes-base.scheduleTrigger and the legacy n8n-nodes-base.cron nodes across workflows and decodes each interval rule into a human-readable string. Answers "what's running at 3am?" without clicking through the n8n UI. Supported rule fields: seconds / minutes / hours / days / weeks / months (with triggerAtHour, triggerAtMinute, triggerAtDay, triggerAtDayOfMonth) and raw cronExpression. One entry per interval - multi-interval rules emit multiple rows. Each row includes workflowId, workflowName, active, nodeName, nodeType, schedule, field, optional cronExpression, and the original raw rule for further inspection. Optional workflowId (single-workflow scan), activeOnly (default true - inactive schedules don't fire), limit (default 100, max 250).
n8n_diff_workflow - compare a workflow's current state against a snapshot. Pass id plus exactly one of snapshotPath or snapshot (inline object). snapshotPath is confined to the configured backupDir (default ~/.n8n-backups): it may be given relative to that directory or as an absolute path inside it, but any path that resolves outside backupDir (including .. traversal) is rejected before the file is read. This keeps the tool from being used as an arbitrary file-read primitive even though it is available without enableEdit. Snapshot accepts both shapes: the flat backup written by n8n_save_workflow / n8n_delete_workflow, and the nested n8n_get_workflow(includeDefinition=true) shape (graph data under definition). Returns summary (counts: added/removed/modified/nameChanged/connectionsChanged/settingsChanged) plus diff with per-node fieldsChanged paths (e.g. parameters.command, parameters.url, disabled). Node matching is two-pass: id first, then name fallback for any unmatched nodes - handles legacy/hand-edited snapshots. Cosmetic changes (position, webhookId) are suppressed by default; pass ignoreCosmetic: false to surface them. Per-node detail is capped at maxModifiedDetails (default 50, max 500); summary.nodesModified counter is uncapped and diff.nodesModifiedTruncated: true flags when detail was clipped. Read-only.
n8n_audit_browser_bridge_usage - scans every workflow for nodes that invoke the browser-bridge CLI. Inspects command (Execute Command + SSH nodes) and jsCode / pythonCode / functionCode (Code + legacy Function nodes). Heuristic: \bbrowser-bridge\.[cm]?js followed by two kebab-slug args; the bare bin form is intentionally not detected to avoid false positives from path mentions like cd /opt/browser-bridge. Returns one finding per (workflowId, nodeName, platform, action) plus a summary of platform×action counts. Optional platform, action, activeOnly (default false), includeArchived (default false), maxWorkflows (default 250, max 1000), concurrency (default 3, max 8). Read-only. Pairs with n8n_scaffold_browser_bridge_node when you need to add another call. Companion repo: browser-bridge.
n8n_scaffold_browser_bridge_node - pure local generator (no n8n API call). Given platform, action, optional input JSON, and mode: "code-node" | "execute-command" (default code-node), emits a ready-to-paste n8n node JSON that mirrors browser-bridge's docs/n8n-usage.md patterns. The Code node uses spawnSync with stdin JSON and surfaces payload.exitCode + stderr so downstream nodes can branch on ok. The Execute Command node uses a quoted <<'JSON' heredoc so the input passes through unmangled. Optional bridgeDir, nodeName, position. Platform/action are validated as kebab slugs - keeps them safe to interpolate into the shell command. Warns when execute-command is used with non-empty input (heredoc bakes the JSON in; no per-item upstream wiring).
n8n_trigger - write tool (hidden unless enableEdit); requires confirm: true. Triggering runs the workflow's nodes (Code / Execute Command / HTTP, etc.) and POSTs to webhooks, all of which can have arbitrary real-world side effects, so it lives behind the same edit gate as the other write tools and refuses without confirm: true. webhookPath is validated client-side: it must resolve to a path under /webhook, /webhook-test, or /form, with no .. traversal or scheme-relative //host form, so a confused agent cannot redirect the call off the base URL. Two modes:
mode: "webhook" + webhookPath - POST (or GET/PUT/DELETE) to the configured base URL + path, with an optional JSON payload. This is the reliable path.
mode: "workflow" + workflowId - attempts POST /api/v1/workflows/:id/execute. Pre-checks that the workflow is active and has a webhook/manual/form trigger. Most n8n builds don't expose this endpoint on the Public API and will 405; the tool surfaces a hint to switch to webhook mode.
n8n_create_workflow - POST /workflows. Creates from structured workflow JSON: name, nodes, connections, optional settings / staticData. Also accepts the full output of n8n_get_workflow (with includeDefinition=true) and backup snapshots directly. Strips read-only fields (id, active, createdAt, updatedAt, isArchived, versionId, triggerCount, tags, shared, meta, pinData) before POSTing - n8n enforces additionalProperties: false on the workflow schema and will 400 on any readOnly field. Runs n8n_validate_workflow on the proposed state as a pre-check; errors block, warnings pass through (pass skipValidation: true to bypass). Optional dryRun:true returns the cleaned POST body and validation issues without writing (no confirm needed for a dry run). Optional projectId and folderId are sent as create-target query params. Requires confirm: true to actually write - the tool accepts an arbitrary nodes graph that will live on the server, so an unconfirmed call (without dryRun) returns ok: false and never touches the API. The new workflow is created INACTIVE; call n8n_activate afterwards if you want triggers running. This is also the primary restore path for n8n_delete_workflow snapshots: read the backup file into definition and call this tool. The restored workflow gets a new id.
n8n_activate / n8n_deactivate - idempotent; both require confirm: true. Activating arms the workflow's triggers, so its nodes can start running automatically (effectively arming arbitrary-code execution); deactivating halts that automation. Deactivating does not cancel running executions.
n8n_save_workflow - before writing: fetches the current version, snapshots it to backupDir as <id>-<timestamp>.json (mode 0600), runs validateWorkflow on the proposed state, and aborts on error-severity issues (pass skipValidation: true to bypass). Requires confirm: true to actually PUT; calling with confirm: false returns ok: false and never touches the API (omitting confirm is rejected at the MCP schema layer). Response includes the backup path and a restoreHint.
n8n_archive_workflow - POST /workflows/{id}/archive. Soft-deletes a workflow: triggers stop firing, the workflow disappears from the default UI list, but the definition and execution history are preserved. Idempotent (archiving an already-archived workflow returns the current state). Requires confirm: true (it deactivates and soft-deletes the workflow); reversible via n8n_unarchive_workflow. Archiving deactivates as a side effect; the response surfaces active: false explicitly. Returns ok: false with reason: "not_found" on 404.
n8n_unarchive_workflow - POST /workflows/{id}/unarchive. Restores an archived workflow. Does NOT reactivate - triggers stay off until you call n8n_activate explicitly. Requires confirm: true; omitting it or passing false returns ok: false and never touches the API. Returns ok: false with reason: "not_found" on 404.
n8n_delete_workflow - DELETE /workflows/{id}. Permanent, irreversible. Before firing the DELETE: fetches the current workflow and snapshots it to backupDir as <id>-DELETED-<timestamp>.json (mode 0600). If the snapshot can't be written, the DELETE is aborted - there is no un-safety-netted path. Requires confirm: true; omitting it or passing false returns ok: false and never touches the API. Returns ok: false with reason: "not_found" on 404 (either before or after the snapshot). Restore is one-call via n8n_create_workflow with the snapshot contents; the restored workflow gets a new id and is created inactive. Deleting does NOT cancel running executions - use n8n_list_executions(workflowId, status='running') + n8n_cancel_execution first if needed. Prefer n8n_archive_workflow for cleanup if you want to preserve the original id.
n8n_cancel_execution - POST /executions/{id}/stop. Closes the triage loop after n8n_search_executions locates a stuck run. Requires confirm: true; omitting it or passing false returns ok: false and never touches the API. Cancellation can leave a multi-step automation partially applied (e.g. a record written but its follow-up notification or cleanup never run). Returns a success summary with the execution's final status, or ok: false with reason: "not_found_or_finished" if the id no longer matches a running execution (404).
n8n_retry_execution - POST /executions/{id}/retry. Creates a NEW execution - the response surfaces both originalExecutionId and newExecutionId so agents can follow up with n8n_get_execution on the retry. Requires confirm: true; omitting it or passing false returns ok: false and never touches the API. Each retry may re-run side effects (HTTP calls, DB writes, etc). Verify the workflow is safe to re-run before confirming. Optional loadWorkflow: true retries against the currently saved workflow instead of the version captured at original execution time. Returns ok: false with reason: "not_found" on 404 or reason: "not_retryable" on 409 (e.g. still running); all other API errors rethrow.
n8n_delete_execution - DELETE /executions/{id}. Permanently removes an execution record: logs, per-node run data, and error payloads are erased from n8n. Requires confirm: true to actually delete; calling with confirm: false returns ok: false and never touches the API (omitting confirm is rejected at the MCP schema layer). Returns ok: false with reason: "not_found" on 404; all other API errors rethrow. Not idempotent from an agent's perspective: the record is gone after the first successful call, so fetch n8n_get_execution first if you may need it later.
n8n_pin_node_data - pin sample data to a node so downstream nodes use it during testing/development without re-running the upstream node. Pairs naturally with n8n_scaffold_browser_bridge_node: scaffold a browser-bridge call, run it once, capture the output, pin it, then iterate on downstream nodes without re-spawning the browser. Inputs: id, nodeName (case-sensitive, must match an existing node), data (1-50 items; raw objects are auto-wrapped into {json: <object>}, items already shaped as {json: ..., binary?: ...} pass through unchanged), optional merge: true to append to existing pinned data instead of replacing (combined still capped at 50), confirm: true. Issues PUT /workflows/{id} with merged pinData plus the existing nodes/connections/settings/staticData (so the PUT does not blank them). Pinned data persists across executions until cleared - easy to forget; the response includes an unpinHint.
n8n_unpin_node_data - clear pinned data on one node (when nodeName is supplied) or the whole workflow (when omitted). Idempotent: clearing a node that wasn't pinned returns ok: true with noop: true and never touches the API. When clearing actually happens, the PUT includes the rest of the workflow body so other fields are not blanked. Requires confirm: true.
n8n_delete_executions - batch form. Client-side fan-out over DELETE /executions/{id} with bounded concurrency (default 3, max 10). Takes an ids array (deduped before fan-out, capped at 50), requires confirm: true. Response surfaces requested/attempted/deleted/alreadyDeleted/failed/skipped/aborted counters plus a results: Array<{id, ok, reason?, message?}> - order is completion order, not input order, so look up by id. 404 per id is treated as already_deleted (idempotent). A 5xx on any id aborts the batch via an AbortController: no new ids are claimed and any already-in-flight fetches are cancelled client-side. Under concurrency N, up to N-1 deletes may have already reached the server before the 5xx is observed, so the batch is best-effort, not transactional - clear signal the server is sick; don't retry blindly. Per-id error messages are passed through the API-key redactor. Compose with n8n_search_executions to purge a known set of noisy runs in one call.
n8n_retry_executions - batch form of retry. Same fan-out shape as n8n_delete_executions: bounded concurrency (default 3, max 10), capped at 50 ids, AbortController on 5xx, results in completion order. Differs in two ways: 404 per id is { ok: false, reason: "not_found" } (NOT idempotent - a missing execution is a real failure to surface), and each successful retry creates a NEW execution whose id is returned per row as newExecutionId. Counters: requested/attempted/retried/notFound/failed/skipped/aborted. Optional loadWorkflow: true retries every id against the currently saved workflow instead of the captured version. Confirm-gated - each retry runs the workflow again and may re-trigger side effects (HTTP calls, DB writes); verify the workflow is safe to re-run before confirming.
n8n_run_audit - POST /audit. Runs n8n's built-in security audit and returns one risk report per requested category: credentials (unused/abandoned), database (SQL-injection-prone expressions in query nodes), nodes (community/unofficial nodes), filesystem (host fs access from nodes), instance (insecure server settings). Each report has risk, sections (with title/description/recommendation/location). The tool also surfaces a flat reports array with per-report sectionCount/locationCount so an agent can decide what to drill into without reparsing the whole audit. Optional categories (omit for all five) and daysAbandonedWorkflow (n8n default 90). Read-only - n8n only inspects, never mutates. Requires the API user to be an instance admin or owner (n8n's audit endpoint enforces this).
n8n_find_workflows_using_node_type - composed read-only scanner. Walks every workflow (paginated, capped at maxWorkflows, default 250 / max 1000) and emits one finding per node matching the requested type. match: "exact" (default) is full-string equality on node.type; match: "contains" is case-insensitive substring (handy for "all Slack nodes across base + community packages"). Optional activeOnly (default false), includeArchived (default false), includeDisabledNodes (default true - disabled nodes are common drift signals worth surfacing), concurrency (default 3, max 8). Returns per-node findings plus a per-workflow summary sorted by match count descending. Per-workflow fetch errors land in fetchErrors instead of failing the whole scan. Pairs with n8n_audit_browser_bridge_usage (which schedules drive my browser-bridge calls?) and n8n_run_audit (which deprecated nodes need replacing?).
n8n_execution_stats - composed read-only aggregator over n8n_list_executions. Per-workflow counts (total/success/error/canceled/running/waiting/other), failure rate (error / (success + error + canceled)), avg + p95 runtime over completed executions, and lastFailureAt / lastSuccessAt. Optional workflowId (single-workflow stats), sinceHours (default 24, max 168 = 7d), maxExecutions (default 1000, max 5000), pageSize (default 250). Pagination stops on the first execution older than the window OR at maxExecutions; stoppedReason is one of "window", "cap", "exhausted". If truncated: true, increase maxExecutions or narrow sinceHours. The totals object includes the same counts + failureRate rolled across all workflows in the window. Useful for "which workflows are flaky?" and "what's running long?"
n8n_list_tags - GET /tags. Returns { data: [{id, name, createdAt, updatedAt}], nextCursor }. Optional limit (default 100, max 250) and cursor (from a previous call's nextCursor). Read-only.
n8n_get_workflow_tags - GET /workflows/{id}/tags. Returns the array of tag objects currently attached. Pairs with n8n_set_workflow_tags for diffs and reattach flows.
n8n_create_tag - POST /tags. Requires confirm: true (consistent with the other mutating tag tools); reversible via n8n_delete_tag. The name is trimmed before send. Returns ok: false with reason: "conflict" on 409 (tag with this name already exists); use n8n_list_tags to find the existing id.
n8n_delete_tag - DELETE /tags/{id}. Confirm-gated. Cascades: n8n removes the tag from every workflow it was attached to. The workflows themselves are NOT deleted, only the tag association. Returns ok: false with reason: "not_found" on 404. To find affected workflows beforehand, use n8n_list_workflows(tags=<name>) or scan n8n_get_workflow_tags.
n8n_set_workflow_tags - PUT /workflows/{id}/tags. REPLACES the workflow's tag set (not append) - pass the full desired list. Empty tagIds: [] clears all tags. Tag ids are deduped before send. Requires confirm: true (reversible by re-setting). Returns ok: false with reason: "not_found" on 404 (the workflow id OR one of the tag ids does not exist; verify both with n8n_list_workflows and n8n_list_tags).
n8n_list_credentials - GET /credentials. Returns metadata only - n8n's API explicitly excludes the data field (encrypted secrets) from list responses, and the tool layer strips data defensively in case of a future regression. Each row: {id, name, type, createdAt, updatedAt, shared[]}. Optional limit (default 100, max 250) and cursor. Requires the API key to belong to an instance owner or admin - non-admin keys get ok: false, reason: "unauthorized" with a clear hint.
n8n_get_credential_schema - GET /credentials/schema/{credentialTypeName}. Returns the raw JSON Schema describing the required data shape for a credential type (e.g. freshdeskApi → { apiKey, domain } required). Use this before calling n8n_create_credential so you know what fields to populate. 404 returns reason: "not_found"; 401 returns reason: "unauthorized".
n8n_find_workflows_using_credential - composed scanner (no direct n8n endpoint). Walks workflows and inspects every node's credentials field. Pass either credentialId (exact, preferred) or credentialName (case-insensitive substring fallback). Returns one finding per (workflowId, nodeName, credentialType) plus a per-workflow summary count. Same fan-out shape as n8n_audit_browser_bridge_usage (bounded concurrency, fetchErrors for per-workflow failures, truncated flag, maxWorkflows default 250). The answer to "I'm rotating Slack creds, where do I need to update?" - run this before n8n_delete_credential to see the blast radius.
n8n_check_disabled_nodes - composed scanner. Surfaces every node with disabled: true across recent workflows. One finding per (workflowId, nodeName, nodeType) plus per-workflow disabled count, sorted desc. Disabled nodes are common drift signals (frozen mid-debug, forgotten cleanup) and the n8n UI doesn't list them anywhere obvious. Same fan-out + filter shape as the other scanners.
n8n_create_credential - POST /credentials. Double-gated: requires both enableEdit AND enableCredentialsWrite (default false). Confirm-gated. data carries plaintext secrets to n8n; the tool layer never echoes data back, even on error - n8n 400s with body content are wrapped to a status-only error before surfacing, so secrets cannot leak via validation messages. Pre-call: use n8n_get_credential_schema to learn the required data shape. Post-call: response includes id, name, type, timestamps; no data. NOT idempotent - calling twice with the same name creates two credentials.
n8n_delete_credential - DELETE /credentials/{id}. Double-gated + confirm-gated. Cascades: every workflow referencing this credential will fail on its next run - call n8n_find_workflows_using_credential first to enumerate the blast radius. 404 returns reason: "not_found". The deleted-credential payload echoed by n8n has data stripped at the tool layer regardless of upstream behavior.
Generate an API key in n8n under Settings → API, then set these env vars in your MCP client config:
Variable | Required | Default | Description |
| yes | - | n8n base URL, e.g. |
| yes | - | n8n Public API key ( |
| no |
| Expose write tools |
| no |
| Second gate (on top of |
| no |
| Where |
| no |
| Cap on inline execution log bytes |
| no |
| HTTP timeout for n8n API calls |
n8nctrl is the standard read-only operator control CLI for shells, cron, and CI. It talks to the same n8n Public API as the MCP server and shares the same client core, so what the agent can read, you can read from a terminal. It exposes only the read/report tools - no create, save, archive, delete, cancel, retry, or trigger. The older n8n-ops bin remains a compatibility alias.
# installed globally, the standard bin is `n8nctrl`:
n8nctrl workflows list --active
n8nctrl workflows get <id> --full
n8nctrl workflows validate <id>
n8nctrl executions list --status error --since 24
n8nctrl executions search "ECONNREFUSED" --scope all
n8nctrl executions stats --since 48
n8nctrl webhooks list
n8nctrl schedules list
n8nctrl tags list
n8nctrl credentials find-usage <credentialId>
n8nctrl nodes find n8n-nodes-base.slack --contains
n8nctrl nodes check-disabled
n8nctrl audit run # exit 1 if the backend is unreachable (cron-friendly)
n8nctrl audit browser-bridge
n8nctrl --json tags list # raw JSON for pipingRun n8nctrl help for the full command and flag list. Configure with the same N8N_BASE_URL / N8N_API_KEY env vars as the MCP server (see the table above). Exit codes: 0 success, 1 runtime error (backend unreachable or a call failed), 2 usage error (unknown command/flag or bad value).
n8nctrl mcp starts the stdio MCP adapter. The n8n-ops-mcp bin remains supported for existing MCP client configs and package launchers. If a launcher referenced the built file path dist/mcp-server.js directly, point it at dist/mcp-bin.js (or dist/cli.js mcp); launchers that use the n8n-ops-mcp bin name need no change.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"n8n": {
"command": "npx",
"args": ["-y", "n8n-ops-mcp"],
"env": {
"N8N_BASE_URL": "https://n8n.example.com",
"N8N_API_KEY": "your-api-key-here"
}
}
}
}claude mcp add n8n \
--env N8N_BASE_URL=https://n8n.example.com \
--env N8N_API_KEY=your-api-key-here \
-- npx -y n8n-ops-mcpAdd --scope user to make it available from any directory instead of only the current project.
codex mcp add n8n \
--env N8N_BASE_URL=https://n8n.example.com \
--env N8N_API_KEY=your-api-key-here \
-- npx -y n8n-ops-mcpWrites the entry to ~/.codex/config.toml under [mcp_servers.n8n]. Verify with codex mcp list.
Any MCP-compatible client that accepts a stdio command + env will work. Point it at npx -y n8n-ops-mcp (or the globally installed n8n-ops-mcp binary) with N8N_BASE_URL and N8N_API_KEY in the environment.
Hermes Agent reads MCP config from ~/.hermes/config.yaml:
mcp_servers:
n8n:
command: "npx"
args: ["-y", "n8n-ops-mcp"]
env:
N8N_BASE_URL: "https://n8n.example.com"
N8N_API_KEY: "your-api-key-here"Then reload from inside a session:
/reload-mcpn8nctrl ships as a first-class OpenClaw plugin through the n8n-ops-mcp package - not an MCP bridge - so it shares the gateway's process, auth profiles, and hooks.
openclaw plugins install clawhub:n8n-ops-mcpAdd the config block to ~/.openclaw/openclaw.json:
{
"plugins": {
"entries": {
"n8n": {
"enabled": true,
"config": {
"baseUrl": "https://n8n.example.com",
"enableEdit": false
}
}
}
}
}Put the API key in your OpenClaw workspace env:
# ~/.openclaw/workspace/.env
N8N_API_KEY=your-api-key-hereRestart the gateway:
systemctl --user restart openclaw-gatewayConfig keys: baseUrl, apiKey, apiKeyEnv, enableEdit, enableCredentialsWrite, maxExecutionLogBytes, requestTimeoutMs, backupDir. See openclaw.plugin.json for the full schema and the Security model for the two-gate write design.
If you want to point OpenClaw at a local clone instead of the registry:
{
"plugins": {
"allow": ["n8n"],
"load": {
"paths": ["/absolute/path/to/n8n-ops-mcp"]
},
"entries": {
"n8n": {
"enabled": true,
"config": {
"baseUrl": "https://n8n.example.com",
"enableEdit": false
}
}
}
}
}Two flags gate write access, with deliberately different blast radii:
enableEdit (default false) - exposes the workflow + execution lifecycle write tools (create/save/archive/delete workflows, activate/deactivate, trigger, cancel/retry/delete executions, pin/unpin node data, tag CRUD). n8n_trigger is gated here too: running a workflow executes arbitrary Code / Execute Command / HTTP nodes and POSTs to webhooks, so it is treated as a write. Mutating tools are confirm-gated (including trigger, activate, deactivate, archive, create_workflow, create_tag, and set_workflow_tags), and the destructive workflow ones snapshot to backupDir first. The read-only n8n_diff_workflow confines snapshotPath reads to backupDir so it cannot be turned into an arbitrary file-read primitive.
enableCredentialsWrite (default false) - second gate, on top of enableEdit, required to expose n8n_create_credential and n8n_delete_credential. An agent that has been overprovisioned with enableEdit cannot inject or destroy credentials without this separate, deliberate config change.
Both flags must be true for credential writes to register. The credential read tools (list-credentials, get-credential-schema, find-workflows-using-credential) and the disabled-node scanner are always available regardless.
Why credentials get a second gate:
create-credential is the only tool in this package where agent input contains plaintext secrets. A prompt-injected or confused agent with enableEdit shouldn't be able to inject credentials.
delete-credential cascades - every workflow referencing the credential fails on its next run. The blast radius is wider than any single workflow operation.
Defense-in-depth on data:
n8n's OpenAPI marks data as writeOnly - the API contract excludes it from every response. We trust but verify: the tool layer strips data from every credential response before surfacing, including success paths and the deleted-credential echo, so a future n8n regression can't leak secrets through us.
On create-credential errors, the n8n response body (which can echo back fragments of submitted data on validation 400s) is replaced at the client layer with a status-only error message. The tool surfaces status + path only. Tests assert no portion of a forced-400 request body reaches the tool response.
What n8n workflows broke today?
Calls n8n_list_executions with status=error, then n8n_get_execution for the failing run.
Which workflow errored with "ECONNREFUSED"?
Calls n8n_search_executions with query: "ECONNREFUSED".
Trigger the "nightly intel" workflow (requires
N8N_ENABLE_EDIT=true)
Calls n8n_list_webhooks to find the path, then n8n_trigger with mode=webhook and confirm: true.
What's running at 3am?
Calls n8n_list_schedules, then filters the result for any schedule whose description contains "03:00" (or whose cronExpression matches an early-morning hour).
What changed in my "intel pipeline" workflow since yesterday's backup?
Calls n8n_diff_workflow with id and snapshotPath pointing to the backup file. Returns added/removed/modified nodes with parameter-level field paths.
Audit my workflows for deprecated Code-node API usage
Calls n8n_list_workflows then n8n_validate_workflow per id, filters for code-node-old-node-ref and code-node-items-global warnings.
Which workflows are flaky this week?
Calls n8n_execution_stats with sinceHours: 168, then sorts by failureRate.
I'm rotating Slack credentials - where do I need to update?
Calls n8n_find_workflows_using_credential with the credential id to enumerate the blast radius before you touch anything.
Deactivate the "experimental-bot" workflow (requires
N8N_ENABLE_EDIT=true)
Calls n8n_list_workflows with a name filter, then n8n_deactivate with confirm: true on the matching id.
Kill the execution stuck on ECONNREFUSED (requires
N8N_ENABLE_EDIT=true)
Calls n8n_search_executions with query: "ECONNREFUSED", then n8n_cancel_execution with confirm: true on the match.
Purge the noisy test-run execution logs from last week (requires
N8N_ENABLE_EDIT=true)
Calls n8n_search_executions to find the ids, then n8n_delete_executions with confirm: true to purge up to 50 in one call. Deletion is irreversible.
Archive the old "staging-bot" workflow - I might need it back someday (requires
N8N_ENABLE_EDIT=true)
Calls n8n_list_workflows with a name filter, then n8n_archive_workflow with confirm: true on the match. Reversible via n8n_unarchive_workflow with confirm: true (you'll still need n8n_activate with confirm: true to turn triggers back on).
Delete the abandoned "poc-scraper" workflow - it's been dead for months (requires
N8N_ENABLE_EDIT=true)
Calls n8n_list_workflows to find the id, then n8n_delete_workflow with confirm: true. A snapshot lands in backupDir first; restore is one-call via n8n_create_workflow with the snapshot. Prefer n8n_archive_workflow if you want to preserve the original id.
n8nctrl is deliberately narrow. It is for operating the n8n you already run, not for authoring new flows from a node catalog.
For a catalog/docs tool that indexes n8n's node library so an agent can scaffold new workflows from node metadata, see n8n-mcp. That is the right tool when you want the agent to know about every node type and its parameters.
n8nctrl is the right tool when you want the agent or CLI to answer "what's broken, what changed, what's risky, what's scheduled" against your live instance and to act on it: triage failed executions, diff against backups, scan for security and credential blast radius, and edit workflows behind explicit, snapshotted write gates.
The two are complementary. One helps build; this one helps run.
Not a node-catalog or workflow-authoring assistant. It does not index n8n's node library or suggest node parameters. Use n8n-mcp for that.
Not a replacement for the n8n UI or its REST API. It is a thin, opinionated operator layer over the n8n Public API, focused on ops questions and safe writes.
Not a hosted service. No daemon, no telemetry. It runs as a local stdio process (or an in-process OpenClaw plugin) and talks only to the n8n instance you configure.
Not a credential exfiltration path. Credential reads return metadata only; credential writes are double-gated and data is stripped from every response branch. See the Security model.
npm install
npm run dev # tsx on mcp-server.ts (MCP stdio)
npm run typecheck
npm test # vitest run
npm run build # tsup bundle to dist/mcp-server.js
npm start # node dist/mcp-server.js (post-build)Or install from source:
git clone https://github.com/lidless-labs/n8nctrl.git
cd n8nctrl
npm install
npm run buildPatches welcome. See CONTRIBUTING.md for what lands easily, SECURITY.md for how to report a vulnerability, and the Code of Conduct.
See CHANGELOG.md for the full version history.
MIT. See LICENSE.
Scan every workflow for nodes that invoke the browser-bridge CLI (Execute Command, Code/Function, or SSH nodes). Returns one finding per (workflowId, nodeName, platform, action) so you can answer 'where am I calling Linktree sync from?' without grepping the n8n DB. Read-only. Heuristic: matches browser-bridge[.js|.cjs] <platform> <action> in command/jsCode strings, including spawn-array form.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Filter findings to a single browser-bridge action (e.g. 'scan-comments'). | |
| platform | No | Filter findings to a single browser-bridge platform (e.g. 'coderlegion'). | |
| activeOnly | No | Only scan active workflows. Default false - inactive workflows often hide stale browser-bridge calls. | |
| concurrency | No | Parallel getWorkflow requests (default 3, max 8). | |
| maxWorkflows | No | Cap on workflows fetched and inspected (default 250). | |
| includeArchived | No | Include archived workflows in the scan. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses that the tool is read-only and uses a heuristic matching method. It explains the matching pattern and the output structure, providing sufficient behavioral context for safe agent usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused paragraph that front-loads the core purpose and provides necessary details without redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the scan scope, matching method, output structure, read-only nature, and parameter defaults. It is complete enough given the moderate complexity and absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All six parameters have schema descriptions, and the description adds value by including default values and rationale (e.g., 'inactive workflows often hide stale browser-bridge calls'). This goes beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans every workflow for nodes invoking the browser-bridge CLI, and specifies the exact node types (Execute Command, Code/Function, SSH). It distinguishes from sibling tools by focusing on a specific use case: locating browser-bridge calls without grepping the database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete example of when to use the tool ('where am I calling Linktree sync from?'), implying usage context. However, it does not explicitly compare to siblings or state when not to use it, so it's clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan workflows and surface every node with disabled: true. One finding per (workflowId, nodeName, nodeType) plus a per-workflow count. Read-only. Disabled nodes are common drift signals — frozen mid-debug, forgotten cleanup — and the n8n UI doesn't surface them in any list view. Bounded-concurrency fan-out; per-workflow fetch errors land in fetchErrors instead of failing the scan.
| Name | Required | Description | Default |
|---|---|---|---|
| activeOnly | No | Only scan active workflows. Default false. | |
| concurrency | No | Parallel getWorkflow requests (default 3, max 8). | |
| maxWorkflows | No | Cap on workflows INSPECTED (default 250). Counted after the active/archived filter, so the scanner may page through more list rows than this when many archived workflows are skipped, but it will not fetch more than `maxWorkflows` full workflow definitions. | |
| includeArchived | No | Include archived workflows. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is highly transparent without annotations. It declares read-only, bounded concurrency fan-out, and that per-workflow errors go to 'fetchErrors' instead of failing the scan. This fully discloses behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and informative, though slightly longer. Each sentence adds value, and the main action is front-loaded. Could be tightened slightly but remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description clearly defines the output structure (one finding per triplet plus count) and error handling. It covers all essential aspects for a scanning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions in the schema are already detailed (e.g., maxWorkflows explains counting logic). The description adds no additional parameter-specific value beyond tool context, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans workflows and surfaces nodes with 'disabled: true'. It specifies output format (per workflowId, nodeName, nodeType plus count) and distinguishes itself from siblings by focusing on disabled nodes, which the UI doesn't surface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains why disabled nodes are important (drift signals) and that the UI doesn't list them, but does not explicitly state when not to use or name alternative tools. However, the context and sibling list imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare a workflow's current state against a snapshot (file path or inline object). Returns a structured semantic diff: nodes added/removed/modified (with per-node field paths), plus name/connections/settings change flags. Snapshot accepts both n8n_save_workflow backup shape (flat) and n8n_get_workflow(includeDefinition=true) shape (nested). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Workflow id to fetch as the 'after' side of the diff. | |
| snapshot | No | Inline snapshot object — accepts the flat backup shape OR the nested n8n_get_workflow(includeDefinition=true) shape. Use this OR `snapshotPath`. | |
| snapshotPath | No | Path to a JSON snapshot file (e.g. n8n_save_workflow backup). MUST resolve inside the configured backupDir (default ~/.n8n-backups); paths outside it or with `..` traversal are rejected. Use this OR `snapshot`. | |
| ignoreCosmetic | No | Suppress position-only and webhookId-only node changes (default true). | |
| maxModifiedDetails | No | Cap on per-node modification entries returned in `diff.nodesModified` (default 50). Counters in `summary` are NOT capped. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It declares the tool is read-only, describes the output shape, and notes accepted snapshot formats. It does not mention error conditions or path restrictions explicitly, but those are covered in the schema descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, no fluff. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema), the description adequately covers the return value structure and snapshot format compatibility. It could mention potential error scenarios but is sufficient for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters with detailed explanations. The description adds value by explaining that the snapshot can be in two different shapes, which is not fully captured in the schema. This goes beyond what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares a workflow's current state against a snapshot and returns a structured semantic diff. It explicitly lists what the diff contains (nodes added/removed/modified with per-node field paths, change flags). This distinguishes it from sibling tools which are listing, auditing, or execution-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing workflow states but does not explicitly state when to use this tool vs alternatives or when not to use it. However, given the sibling tools, none perform diffing, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate execution stats over a recent window. Computes per-workflow counts (total/success/error/canceled/running/waiting), failure rate, avg + p95 runtime, last failure + last success timestamps. Composed read-only — paginates /executions and stops on the window boundary or maxExecutions. Useful for 'which workflows are flaky?' and 'what's running long?'. Pagination is best-effort: if truncated: true, increase maxExecutions or narrow sinceHours.
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | Page size for /executions calls (default 250). | |
| sinceHours | No | Window in hours (default 24, max 168 = 7d). Pagination stops when an execution older than the window is seen. | |
| workflowId | No | Restrict stats to a single workflow id. Omit for per-workflow stats across the instance. | |
| maxExecutions | No | Hard cap on executions inspected (default 1000). If `truncated: true`, increase this or narrow `sinceHours`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares itself 'composed read-only', explains pagination against /executions, mentions best-effort pagination and truncation. No annotations present, so description handles transparency well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two-sentence core, followed by usage phrase and pagination note. No wasted words; front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers parameters, usage, behavior, and limitations. Lacks output format details (e.g., map per workflow), but acceptable for an aggregation tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds context beyond schema: workflowId optional for per-instance stats, sinceHours window stops pagination, maxExecutions with truncation hint, pageSize default. Schema coverage is 100%, but description enriches understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Aggregate execution stats over a recent window' and lists computed fields (counts, failure rate, runtimes, timestamps). It distinguishes from siblings like n8n_list_executions by focusing on aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides practical use cases ('which workflows are flaky?') and pagination advice ('if truncated: true, increase maxExecutions or narrow sinceHours'). However, it does not explicitly contrast with alternatives like n8n_search_executions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan workflows and surface every node that references a given credential. Pass either credentialId (exact, preferred) or credentialName (case-insensitive substring fallback). Returns one finding per (workflowId, nodeName, credentialType) plus a per-workflow summary count. Read-only. Bounded-concurrency fan-out; per-workflow fetch errors land in fetchErrors instead of failing the whole scan. Pairs with n8n_run_audit and is the answer to 'I'm rotating creds, where do I need to update?' before calling n8n_delete_credential.
| Name | Required | Description | Default |
|---|---|---|---|
| activeOnly | No | Only scan active workflows. Default false. | |
| concurrency | No | Parallel getWorkflow requests (default 3, max 8). | |
| credentialId | No | Exact credential id to match (preferred). Either this or credentialName is required. | |
| maxWorkflows | No | Cap on workflows INSPECTED (default 250). Counted after the active/archived filter, so the scanner may page through more list rows than this when many archived workflows are skipped, but it will not fetch more than `maxWorkflows` full workflow definitions. | |
| credentialName | No | Case-insensitive substring match on credential name. Either this or credentialId is required. | |
| includeArchived | No | Include archived workflows in the scan. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond what annotations would cover: 'Read-only. Bounded-concurrency fan-out; per-workflow fetch errors land in fetchErrors instead of failing the whole scan.' It also explains the return structure. Given no annotations, this fully informs the agent of the tool's operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose. It is slightly verbose but every sentence adds necessary information. Could be trimmed slightly, but remains effective and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description thoroughly explains the return format: 'one finding per (workflowId, nodeName, credentialType) plus a per-workflow summary count.' It also accounts for error handling. Given the tool's complexity with 6 parameters, this is comprehensively complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant value by explaining the interplay between parameters (e.g., credentialId vs credentialName) and clarifying defaults and behaviors for maxWorkflows and concurrency. For instance, it explains how maxWorkflows is counted and that concurrency has a default of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Scan workflows and surface every node that references a given credential.' It also distinguishes itself from siblings by noting it 'Pairs with n8n_run_audit and is the answer to... before calling n8n_delete_credential.' This specificity helps the agent differentiate from other tools like n8n_find_workflows_using_node_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool, instructing to pass either credentialId (preferred) or credentialName. It contextualizes usage: 'before calling n8n_delete_credential.' While it does not explicitly state when not to use it, the guidance is sufficient for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan workflows and surface every node matching a given type (e.g. 'n8n-nodes-base.slack'). Returns one finding per matching node + a per-workflow summary so agents can answer 'where am I calling Slack?' or 'which workflows still use the legacy HTTP Request node?' without grepping the n8n DB. Read-only. Bounded-concurrency fan-out; per-workflow fetch errors land in fetchErrors instead of failing the whole scan.
| Name | Required | Description | Default |
|---|---|---|---|
| match | No | Match mode (default 'exact'). 'contains' is case-insensitive substring match. | |
| nodeType | Yes | n8n node type to search for (e.g. 'n8n-nodes-base.slack', 'n8n-nodes-base.httpRequest'). | |
| activeOnly | No | Only scan active workflows. Default false. | |
| concurrency | No | Parallel getWorkflow requests (default 3, max 8). | |
| maxWorkflows | No | Cap on workflows fetched (default 250). | |
| includeArchived | No | Include archived workflows in the scan. Default false. | |
| includeDisabledNodes | No | Include disabled nodes in findings. Default true (disabled nodes are common drift signals). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Read-only' and describes concurrency behavior ('Bounded-concurrency fan-out') and error handling ('per-workflow fetch errors land in fetchErrors'). It also mentions the return structure (one finding per node and per-workflow summary). This provides adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a final technical note. It is front-loaded with the purpose and provides essential details without unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, 1 required) and no output schema, the description adequately covers the tool's behavior, concurrency, error handling, and return structure. It could be improved by stating prerequisites or permissions, but overall it is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description does not add additional context beyond the schema; it focuses on overall behavior. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: scanning workflows to surface nodes matching a given type, with concrete examples like 'n8n-nodes-base.slack' and the legacy HTTP Request node. It distinguishes itself from siblings like n8n_find_workflows_using_credential by focusing on node type, and provides a use case ('where am I calling Slack?').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases ('where am I calling Slack?', 'which workflows still use the legacy HTTP Request node?') and implies when not to use (e.g., for credential search, use n8n_find_workflows_using_credential). However, it does not explicitly list alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the JSON schema for a credential type via GET /credentials/schema/{credentialTypeName}. Returns the raw JSON Schema document describing the required data shape (e.g. freshdeskApi requires { apiKey, domain }). Use this BEFORE calling n8n_create_credential so you know what fields to populate. 404 on unknown type returns { ok: false, reason: 'not_found' }. 401 surfaces the admin/owner role requirement.
| Name | Required | Description | Default |
|---|---|---|---|
| credentialTypeName | Yes | n8n credential type name (e.g. 'githubApi', 'slackOAuth2Api'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses GET method, raw JSON Schema return, error responses (404 with reason, 401 requiring admin/owner role). Suffices for agent to understand behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, first states purpose and endpoint, second gives usage and error info. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool without output schema, description covers return type, errors, usage order. Complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description. Description adds example (freshdeskApi requires { apiKey, domain }) providing meaningful context beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch the JSON schema for a credential type', specifying the HTTP endpoint and resource. It distinguishes from sibling tools like listing or using credentials, and gives context for use before creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this BEFORE calling n8n_create_credential' and mentions error responses (404, 401). Provides clear context for when to use, though no explicit alternatives for when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single n8n execution by id. Returns status, mode, timing, and per-node run data. Large run logs are truncated with a tail hint. Error executions include the raw error verbatim.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Execution id (from n8n_list_executions). | |
| includeRunData | No | Include per-node run log. Default true. Turn off for just status + error summary. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behaviors: truncation of large logs with a tail hint, raw error inclusion in error executions. This goes beyond basic functionality. However, it does not explicitly state idempotency or lack of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no redundancy. It immediately states the purpose, then lists key return data and special behaviors. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description adequately explains what the tool returns and its edge cases (truncation, error handling). It could be more complete by mentioning response format, but it is sufficient for a fetch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters with descriptions. The tool description adds extra context: for id it links to n8n_list_executions, and for includeRunData it explains the default and use case. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (fetch) and resource (n8n execution by id). It lists returned fields (status, mode, timing, per-node run data), and differentiates from siblings like list/search by focusing on a single id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an execution id and need details. It does not explicitly state when to avoid or mention alternatives, but the context hints are clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single n8n workflow by id. Returns metadata and optionally the full node graph. Resolves against the live workflow, not the workflow_entity row directly.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Workflow id (from n8n_list_workflows). | |
| includeDefinition | No | Include full nodes+connections JSON. Off by default. Turn on when you need to inspect or edit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a key behavioral trait: resolves against live workflow, not the raw entity row. However, with no annotations, it should also mention error handling, auth requirements, or rate limits. The description is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information. The description is front-loaded with the core action, and every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description hints at return values ('metadata and optionally the full node graph'), which is sufficient for a simple fetch. The context about live vs entity is valuable. Could elaborate on error responses but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining where to get the id ('from n8n_list_workflows') and providing usage context for includeDefinition parameter. This exceeds the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Fetch' and resource 'single n8n workflow by id'. Differentiates from sibling list/diff tools by specifying it returns metadata and optionally the full node graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to enable includeDefinition ('when you need to inspect or edit') and notes that it resolves against the live workflow. Lacks explicit when-not-to-use or comparison with siblings like n8n_audit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the tags currently attached to a workflow via GET /workflows/{id}/tags. Returns the array of {id, name} tag objects (also includes createdAt/updatedAt). Read-only. Pairs with n8n_set_workflow_tags for diffs and reattach flows.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Workflow id (from n8n_list_workflows). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Read-only' and lists return fields, but does not mention rate limits, authentication needs, or error behavior (e.g., if workflow ID is invalid). Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Critical information is front-loaded (verb, resource, endpoint, return). Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description covers purpose, return structure (including fields beyond id/name), endpoint path, and pairing with a sibling. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the 'id' parameter is already described in the schema. The description does not add additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'tags attached to a workflow', specifies the HTTP endpoint, and distinguishes from sibling n8n_set_workflow_tags by mentioning pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly pairs with n8n_set_workflow_tags for diffs and reattach flows, but does not contrast with n8n_list_tags (a sibling that lists all tags globally). Context is clear but not fully exclusive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List credentials via GET /credentials. Returns metadata only — n8n's API explicitly excludes the data field (the encrypted secrets). Each row: {id, name, type (e.g. 'githubApi'), createdAt, updatedAt, shared[]}. Read-only. Requires the API user to be an instance owner or admin — non-admin keys get 401 with a clear hint. The tool defensively strips any data field that might appear in a future regression.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max credentials returned (default 100). | |
| cursor | No | Pagination cursor from a previous call's `nextCursor`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: read-only, returns only metadata (no data field), requires admin/owner, defensive stripping of data field, and error behavior for unauthorized users. It does not discuss rate limits or side effects, but such details are unlikely needed. Transparency is good, so score 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the core action. It avoids redundancy, though the statement about defensive stripping slightly overlaps with the 'metadata only' claim. It is efficient but not maximally concise, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return structure (each row). It covers authentication requirements, read-only nature, and defensive behavior. The tool is simple, and the description covers all necessary context for an agent to use it correctly. Score 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both limit and cursor have clear descriptions). The tool description adds no additional meaning to the parameters beyond what the schema provides. Per guidelines, baseline is 3 when coverage is high, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists credentials and returns metadata only, with a detailed row structure. It distinguishes from sibling tools implicitly by specifying the resource, but does not explicitly contrast with other list tools like n8n_list_workflows. A score of 4 is appropriate for a clear, specific purpose with slight room for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: read-only, requires admin/owner permissions, and mentions the 401 error for non-admin keys. However, it does not explicitly advise when to use this tool versus alternatives like n8n_get_credential_schema or n8n_find_workflows_using_credential. The guidance is solid but lacks explicit alternatives, warranting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent n8n executions with optional filters. Returns id, workflowId, workflowName, status, mode, startedAt, stoppedAt. Use n8n_get_execution for the full run log.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows (default 50). | |
| status | No | Filter by execution status. | |
| workflowId | No | Filter to a single workflow id. Omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool is read-only (listing executions) and lists return fields. It does not mention ordering (e.g., most recent first), authentication requirements, or pagination behavior beyond the limit parameter. For a simple list tool, this is adequate but lacks some context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence covers purpose and return fields, the second provides a direct alternative. Extremely concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explicitly lists return fields. It covers the tool's core functionality and provides a clear alternative. Minor missing details like default sorting order, but overall sufficient for a simple list tool with well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all three parameters (workflowId, status, limit). The description adds no additional parameter information beyond what's in the schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'n8n executions', and the scope 'recent with optional filters'. It also specifies the exact fields returned (id, workflowId, workflowName, etc.), distinguishing it from sibling tools like n8n_get_execution and n8n_search_executions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear alternative: 'Use n8n_get_execution for the full run log.' This helps the agent decide when to use this tool vs. a more detailed one. However, it does not explicitly mention when not to use it or compare with n8n_search_executions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Surface every schedule trigger across workflows so you can answer 'what's running at 3am?' without clicking through the n8n UI. Walks scheduleTrigger and legacy cron nodes, decodes their interval rules into human-readable strings (e.g. 'every 2 hours', 'daily at 03:00', 'cron: 0 */6 * * *'), and returns workflow context + the raw rule for further inspection. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | When workflowId is omitted, max workflows to fetch and scan (default 100). | |
| activeOnly | No | Only include schedules from active workflows. Default true — inactive schedules don't fire. | |
| workflowId | No | Restrict the scan to a single workflow. Omit to scan recent workflows. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description declares 'Read-only' and describes scanning behavior (scans recent workflows when workflowId omitted, defaults to active only). This adds value beyond the schema, though limitations like 'recent' are not precisely defined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the main purpose front-loaded. The second sentence is packed with detail but still efficient. No filler words, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description vaguely mentions returning 'workflow context + raw rule' but lacks specifics on data structure. It covers tool purpose and parameter usage well but omits return format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter. The tool description does not add additional semantic details beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool surfaces schedule triggers across workflows, decodes interval rules, and returns workflow context. It distinguishes from sibling tools which focus on credentials, nodes, and executions, none of which list schedules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides context ('answer what's running at 3am?') but does not explicitly state when to use vs alternatives or when not to use. There are no direct sibling competitors, so guidance is adequate but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List workflow tags via GET /tags. Returns { data: [{id, name, createdAt, updatedAt}], nextCursor }. Read-only; pairs with n8n_set_workflow_tags + n8n_get_workflow_tags for cross-cutting workflow metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max tags returned (default 100). | |
| cursor | No | Pagination cursor from a previous call's `nextCursor`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states read-only behavior and details the return format including pagination (nextCursor), providing full behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the action and return format, with no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description thoroughly covers purpose, usage, behavior, and output format for a list operation, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described in the input schema. The description adds value by mentioning the output's nextCursor, clarifying the cursor parameter's source, but does not significantly extend beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'workflow tags', identifies the HTTP method GET /tags, and distinguishes from siblings by referencing related tools for setting and getting tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it is read-only and pairs with specific sibling tools for cross-cutting workflow metadata, providing clear context. It lacks explicit when-not-to-use guidance but is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Surface webhook and form-trigger paths from n8n workflows so agents can call n8n_trigger with mode='webhook' without opening the n8n UI. Returns workflowId, workflowName, nodeName, method, path, and a fully-formed triggerUrl.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max workflows to scan when workflowId is omitted (default 50). | |
| activeOnly | No | Only include active workflows. Default true. | |
| workflowId | No | Restrict to a single workflow. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Lists return fields but lacks details on side effects, permissions, or whether it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff: first states purpose, second lists return fields. Perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description lists all key return fields. Could mention array format or pagination, but sufficient for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions; the description adds no extra meaning beyond the schema, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool surfaces webhook and form-trigger paths and lists specific return fields, distinguishing it from sibling tools like n8n_list_workflows. The verb 'surface' is slightly vague but the description is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage as a prerequisite for n8n_trigger with mode='webhook', but does not explicitly state when not to use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List n8n workflows with optional filters. Returns id, name, active state, tags, updatedAt. Use n8n_get_workflow to pull the full definition.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Case-insensitive substring match on workflow name. | |
| tags | No | Comma-separated tag names to filter by. | |
| limit | No | Max rows (default 100). | |
| active | No | Filter by active state. Omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the return schema (id, name, etc.) but doesn't mention pagination, sort order, or that it's a read-only operation. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the verb 'List'. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return fields, the 4 parameters are fully described in the schema, and a sibling alternative is mentioned. However, it lacks details on default sorting or pagination beyond the limit parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema's own parameter descriptions, which are already clear. No parameter info in the description that isn't already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists workflows with optional filters and specifies the returned fields (id, name, active state, tags, updatedAt). It explicitly distinguishes from n8n_get_workflow by directing users to that sibling for full definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it lists workflows with filters and points to n8n_get_workflow when full definition is needed. While it doesn't explicitly state when not to use it or list exclusions, the alternative is clearly named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate n8n's built-in security audit via POST /audit. Returns one risk report per requested category: credentials (unused/abandoned), database (SQL injection-prone expressions), nodes (community/unofficial nodes), filesystem (host fs access), instance (insecure server settings). Each report has risk, sections (with title/description/recommendation/location). Read-only — n8n only inspects, never mutates. Requires the API user to be an instance admin or owner.
| Name | Required | Description | Default |
|---|---|---|---|
| categories | No | Restrict the audit to specific risk categories. Omit for all five. | |
| includeDetails | No | Return full per-finding `location` arrays (credential ids/names, node ids). Default false: locations stripped from audit body, only counts surfaced. | |
| daysAbandonedWorkflow | No | Days a workflow must go unexecuted to count as abandoned in the credentials report. n8n default is 90. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It explicitly states the tool is read-only ('never mutates'), details the output structure (risk reports with sections), and notes authorization requirements. This is strong transparency, though it could mention potential side effects like performance impact or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4-5 sentences) and front-loads the core purpose. Every sentence adds value: main action, category details, output structure, read-only nature, and auth requirement. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 optional parameters, no output schema), the description covers the essential output format and parameter behavior. It explains the report structure and the effect of includeDetails. However, it does not describe the default when categories is omitted or error conditions, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it reiterates category names but does not clarify values, defaults, or relationships between parameters. It is adequate but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Generate n8n's built-in security audit via POST /audit'), specifies the resource, and describes the five risk categories. While it does not explicitly distinguish from siblings, the name and context make its purpose distinct among the listed tools (e.g., no other audit tool covers all these categories).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions a prerequisite (admin/owner role) but does not specify when to choose this audit over other audit-related siblings like n8n_audit_browser_bridge_usage or n8n_check_disabled_nodes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a ready-to-paste n8n node JSON that calls the browser-bridge CLI for a given (platform, action, input). Mirrors the patterns in browser-bridge's docs/n8n-usage.md so n8n workflows don't need to rediscover the spawn/heredoc shape every time. Pure local generator — no n8n API call. Default mode 'code-node' uses spawnSync with stdin JSON; 'execute-command' uses an Execute Command node with a quoted heredoc.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Which n8n node shape to emit. 'code-node' (default) handles JSON I/O via spawnSync. 'execute-command' is a heredoc shell call. | |
| input | No | JSON input passed on stdin to the browser-bridge call. | |
| action | Yes | Browser-bridge action (e.g. 'scan-comments', 'draft-post'). | |
| nodeName | No | Override the generated node name. Default 'Browser Bridge: <platform> <action>'. | |
| platform | Yes | Browser-bridge platform slug (e.g. 'coderlegion'). | |
| position | No | n8n canvas position [x, y]. Default [0, 0]. | |
| bridgeDir | No | Absolute path to the browser-bridge checkout on the n8n host. Default matches docs/n8n-usage.md. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool generates JSON locally without calling the n8n API, and describes two modes. It does not explicitly state how the output is delivered (e.g., stdout), but 'ready-to-paste' implies the JSON is output. The description is consistent and clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: one for main purpose, one for context, and one for mode details. It is front-loaded with the primary action and contains no filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, enum), the schema provides full parameter coverage. The description adds context about the local generation and modes. It could mention the output format more explicitly, but overall it is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so a baseline of 3 is appropriate. The description adds value by explaining the two modes and the default behavior, but most parameter semantics are already covered in the input schema. Little extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a ready-to-paste n8n node JSON for a given platform, action, and input. It specifies the resource (n8n node for browser-bridge) and verb (generate), and distinguishes from sibling tools (which are other n8n utilities not related to scaffolding).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to create an n8n node for browser-bridge without rediscovering the spawn/heredoc pattern. It also explains there are two modes ('code-node' and 'execute-command') with default indicated. However, it doesn't explicitly state when NOT to use it or name alternative tools, though none of the siblings are relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Text-search recent n8n executions without paging through them one by one. Fetches each candidate with includeData=true, then greps the error payload (scope='error', default) or the full per-node run log (scope='all'). Returns matched executions with workflow context and a snippet around each hit. Snippets are raw run data with the API key redacted — with scope='all' they may still contain credentials or payload data from node outputs, so treat as sensitive.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max executions to scan (default 50). | |
| query | Yes | Case-insensitive text to search for (e.g. 'ECONNREFUSED'). | |
| scope | No | 'error' (default) searches only the execution error payload. 'all' also greps the full per-node run log — slower and may return raw node output in snippets. | |
| status | No | Filter executions by status before searching. Default 'error'. | |
| maxMatches | No | Stop after this many matches (default 20). | |
| workflowId | No | Filter to a single workflow id. Omit to scan across all workflows. | |
| snippetChars | No | Context window around each match (default 160). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool fetches data with includeData=true, greps specific fields, redacts API keys, and warns that credentials may appear in snippets with scope='all'. It also notes that scope='all' is slower. This covers key behavioral traits, though it doesn't mention rate limits or performance impact beyond slowness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4-5 sentences) with no unnecessary words. It front-loads the core purpose and then efficiently covers scope, return format, and security notes. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what is returned: matched executions with workflow context and snippets, including redaction and sensitivity. However, it could benefit from a brief note on the structure of matched data (e.g., keys returned) or pagination behavior. Still, it's sufficient for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds significant value beyond schema by explaining the overall flow, scope behavior, snippet content, and sensitivity implications. This enrichment justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it performs text-search across executions, distinguishing it from simple listing tools like n8n_list_executions. It uses specific verbs ('Text-search', 'Fetches', 'greps') and resources ('n8n executions'), with clear scope differentiation ('error' vs 'all'). This separates it from siblings that list or fetch single executions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (to search recent executions without paging) and provides context on scope choices and sensitivity. While it doesn't explicitly state when not to use it or compare to alternatives like list_executions, it gives enough practical guidance for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Static checks on a workflow: deprecated node types (function → code), old Code-node API usage ($node[], items global, require()), orphan nodes, disabled nodes, and missing trigger. Returns a list of issues with severity.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Workflow id (from n8n_list_workflows). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It lists the checks performed and indicates a return list with severity, but does not explicitly state that the tool is read-only or has no side effects, though 'static checks' implies non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every part adds value. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description covers the main behavioral aspects and return format. However, it could be slightly improved by specifying the structure of the returned issues list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter 'id' with a clear description. The tool description does not add additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'static checks' and the resource 'workflow', and lists specific checks (deprecated node types, old Code-node API usage, etc.), distinguishing it from siblings like n8n_check_disabled_nodes which may only check for disabled nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for static analysis before deployment but does not explicitly state when to use this tool versus alternatives like n8n_check_disabled_nodes, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.14.0n8n_audit_browser_bridge_usagen8n_check_disabled_nodesn8n_diff_workflown8n_execution_statsn8n_find_workflows_using_credentialn8n_find_workflows_using_node_typen8n_get_credential_scheman8n_get_executionn8n_get_workflown8n_get_workflow_tagsn8n_list_credentialsn8n_list_executionsn8n_list_schedulesn8n_list_tagsn8n_list_webhooksn8n_list_workflowsn8n_run_auditn8n_scaffold_browser_bridge_noden8n_search_executionsn8n_validate_workflowEvery tool has a clearly distinct purpose. For example, execution-related tools (n8n_execution_stats, n8n_get_execution, n8n_list_executions, n8n_search_executions) each focus on different aspects: aggregated stats, single execution detail, listing, and text search. Similarly, workflow scanning tools target different signals (disabled nodes, credential usage, node type usage). No two tools overlap in function.
All tool names follow the consistent pattern `n8n_<verb>_<resource>` using snake_case and imperative verbs (e.g., list, get, check, diff, find, run, scaffold, validate). The convention is uniform and predictable, making it easy for an agent to infer purpose from the name.
With 20 tools, the server is on the higher end but still appropriate for the broad domain of n8n operations (workflows, executions, credentials, tags, schedules, webhooks, auditing, node generation). Each tool provides distinct value, and the count reflects the complexity of the platform without being excessive.
The tool set covers inspection, auditing, validation, and comparison well, but lacks mutation tools for creating, updating, or deleting workflows and credentials. While the server's focus appears to be ops/inspection, the absence of basic CRUD operations for key resources creates notable gaps that may require agents to fall back to other means.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
n8n MCP — query your own n8n instance (BYO).
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Create, browse, remix, collaborate on, and run durable AI workflow nodes from MCP hosts.
Free public MCP for AI agents — 193 tools, 44 workflows. No API key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lidless-labs/n8nctrl'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
