A few weeks ago n8n released the ability to create and update workflows using the official n8n MCP server, and I know many of you are using it already.
We’d love your feedback and thoughts so far (I’m from n8n):
General feedback
How reliable has workflow creation been for you? Are the generated workflows landing close to what you’d build manually, or are you spending a lot of time fixing things up after? Any specific pain points or things that surprised you?
Tips & tricks
If you’ve found prompting patterns, workflow structures, or setups that consistently get better results out of the MCP server, share them here. Would love to start collecting what’s actually working.
Skills
If you could add anything to an official n8n MCP server skill, what would it be? Think node coverage, error handling, testing, documentation generation , or whatever you’ve been wishing it could do. And if you’ve already built your own custom skills, drop them below - I would love to see what the community is doing with it.
Good, bad, or weird, all feedback is appreciated!
Thanks!
Ophir
p.s.
If you provide any feedback, Please add the version number you’re using - thanks!!
Been using it for a while and yes its a great thing to work with it and already made the work a lot easier in my agency but we still have to change something to get the best out of the workflows especially the error triger nodes etc.
Hi Ophir, feedback from real usage — Version: n8n@2.20.7
I run the official n8n MCP alongside czlonkowski’s n8n-mcp simultaneously. The official handles new workflow creation via the TypeScript SDK (type-checking before deployment is genuinely great). czlonkowski fills the gaps: partial workflow edits, template search, auto-fix, version rollback, and credential management.
The two complement each other well, closing those gaps in the official server would make it the only tool needed.
I am reporting an issue with the update_workflow tool in the n8n MCP server.
According to the n8n MCP documentation, starting with n8n v2.20.0, update_workflow should support partial
updates instead of rewriting the entire workflow.
Expected behavior:
update_workflow accepts an ordered list of operations.
Each operation updates only a specific part of the workflow.
The batch of operations is atomic.
If one operation fails, none of the changes should be persisted.
Documentation reference:
n8n MCP server tools reference: update_workflow
Actual behavior
In my environment running n8n 2.21.8, atomic partial updates through update_workflow do not work as expected.
What I observe:
the MCP tool exposed in my environment appears to support only the older update_workflow({ workflowId, code })
shape;
there is no visible operations parameter for partial updates;
the following operations mentioned in the docs are not available through the exposed tool interface:
updateNodeParameters
setNodeParameter
addNode / removeNode
addConnection / removeConnection
renameNode
setNodePosition
setNodeDisabled
as a result, I cannot perform atomic partial updates as described in the documentation.
Steps to reproduce
Connect to the n8n MCP server.
Inspect the available update_workflow tool schema.
Try to perform a partial update using operations such as:
update a node parameter
add or remove a connection
disable a node
Observe that:
the tool does not expose operations, or
the update does not behave as an atomic partial update.
Expected behavior
update_workflow should support partial workflow updates through an ordered list of operations, and those operations
should be applied atomically.
Environment
n8n version: 2.21.8
deployment type: self-hosted / Docker
Additional notes
I may be missing a configuration detail, but from the tool schema exposed in my environment the update_workflow
interface does not match the partial-update behavior described in the documentation.
If this is expected, it would be helpful to clarify:
whether partial updates are available only in a newer MCP server version;
whether a specific server-side upgrade is required;
or whether the MCP client must refresh its tool schema after the update.
Thank you for the very detailed breakdown!
I’ve asked the dev team to take a look and reply here.
In the meantime, I suspect it might be MCP tool definition caching on the client side.
Something similar happened to me when I first updated my n8n instance. After I totally quit Claude Code (I use the desktop version) and restarted it, the problem went away.
Can you check to see if this might be the issue?
Thanks!!
@Next_Metal
I just checked and we have a typo in the docs. So sorry about that.
The update_workflow tool switched to partial updates with version 2.22.0, not version 2.20.0
@Sarim
The update tool was just updated to partial updates as of version 2.22.0
We’ll be officially announcing this soon together with a few other small updates to the MCP server.
Using it with Claude and it’s been useful for prototyping but not production-ready without significant cleanup. The most reliable prompting pattern I’ve found: describe the workflow in terms of “what data comes in, what transformation happens, what comes out” rather than naming specific nodes. Saying “when a webhook receives a POST with an order JSON, extract the items array, loop over each, and send a Slack message for any item where quantity < 5” produces much cleaner output than listing the nodes you expect. Generated expression syntax still needs manual review though - the MCP often uses slightly off field references that need fixing.
@DGIT - the n8n MCP server needs to be publicly accessible for Claude to reach it. If you’re running n8n on localhost, Claude’s API calls can’t reach that address - it’s a network accessibility issue, not an n8n limitation. The options are: 1) expose your local n8n via a tunnel (ngrok, Cloudflare Tunnel) and use that public URL as your MCP server endpoint in Claude’s settings, or 2) move to n8n cloud or a VPS. The MCP server feature itself works fine once the endpoint is reachable.
