tmolavitmolavi/n8n-agent-skills/skills/n8n-mcp-tooling/SKILL.md

n8n-mcp-tooling

Skill1 starsChanged 3 months agoMITView on GitHub

Use when configuring n8n MCP servers, choosing tools across official and community MCPs, routing generate/lint/explain/CRUD calls, or debugging MCP auth. Covers official instance MCP, AutomateLab, czlonkowski, salacoste, leonardsellem.

In this repository17 other files it gives its agents.
- AGENTS.mdAGENTS.md
- llms.txtllms.txt
- n8n-agentsSkill
- n8n-ai-seo-geo-automationSkill
- n8n-binary-dataSkill
- n8n-code-nodesSkill
- n8n-credentials-securitySkill
- n8n-data-tablesSkill
- n8n-debuggingSkill
- n8n-error-handlingSkill
- n8n-expressionsSkill
- n8n-loopsSkill
- n8n-node-configurationSkill
- n8n-production-opsSkill
- n8n-subworkflowsSkill
- n8n-workflow-lifecycleSkill
- using-n8n-skillsSkill

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific
could be automatic: a setting could enforce it

Distinctive:
When configuring API-key MCPs:
line 36
Distinctive:
Never commit API keys. Use env / secret manager.
line 44
Distinctive:
Prefer one write-capable server.
line 60

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

n8n MCP Tooling

Author: Taghi Molavi

Goal

Give the agent a stable mental model across heterogeneous n8n MCP servers. Tool names differ; intents do not.

Intent → tool family

Intent	Official-ish names	AutomateLab	Notes
NL → workflow JSON	`create_workflow_from_code` / SDK	`workflow_generate`	Always lint after generate
Lint / validate	`validate_workflow`, `validate_node_config`	`workflow_lint`	Run before activate
Node schema	`get_node_types`	(corpus servers)	Prefer live schema
CRUD list/get	`search_workflows`, `get_workflow_details`	`workflow_list`, `workflow_get`
Create	create_*	`workflow_create`	Create inactive
Activate	`publish_workflow` / activate	`workflow_activate`	After validate+test
Diagnose run	execution search + details	`execution_explain`, `execution_timeline`	#1 debug path
Diff	—	`workflow_diff`	Reviews/PRs
Custom node TS	—	`node_scaffold`	Packages
Templates/docs search	—	czlonkowski tools	Huge corpus

Safety policy (recommend to user)

When configuring API-key MCPs:

N8N_MCP_READ_ONLY=1          # if supported
N8N_MCP_DISABLED_TOOLS=workflow_create,workflow_activate
N8N_MCP_ALLOWED_TAGS=staging,dev

Never commit API keys. Use env / secret manager.

Config snippets

Ready files in repo configs/:

configs/mcp.official-http.example.json — instance-level MCP (OAuth HTTP)
configs/mcp.automatelab.example.json — debugging-first server
configs/mcp.czlonkowski.example.json — node corpus server
configs/mcp.salacoste.example.json — workflow builder
configs/mcp.leonardsellem.example.json — classic bridge
configs/mcp.multi.example.json — compose two servers with distinct names

Multi-server hygiene

Give each server a unique key (n8n-official, n8n-lint, …).
Prefer one write-capable server; others read-only/lint.
Tell the user which server you will write with.
On tool-name drift: list tools, map intent, do not invent names.

Official instance MCP prerequisites

n8n ≥ 2.2.0 (prefer latest stable)
Settings → Instance-level MCP enabled
Base URL only; path often /mcp-server/http
OAuth browser auth on first use

API-key MCP prerequisites

n8n API key (Settings → API)
N8N_API_URL usually https://host/api/v1 (verify per server docs)
Network path from the agent host to n8n

Default chains

Generate → ship (API MCP):
workflow_generate → workflow_lint → fix → (user OK) workflow_create → test → workflow_activate

Official SDK path:
design with skills → validate_workflow → create/update → get_workflow_details → test → publish

Debug empty output:
execution_list (error/recent) → full data → execution_explain → open failing node params → fix expressions/wiring → retest

References

references/SERVER_MATRIX.md
references/AUTH_AND_POLICY.md

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free