Use when an n8n-mcp account targets more than one n8n instance — i.e. the `n8n_instances` tool is available, the user mentions multiple n8n instances or environments (prod vs staging, several teams or clients), a workflow / datatable / credential / execution call returns an unexpected NOT_FOUND or r

Working with multiple n8n instances over MCP When the n8n instances tool is available, the user has multi instance mode on: one MCP connection can reach several n8n instances (e.g. prod , staging , or one per client/team). There are two ways to say which instance a call should hit: Name it on the call — every n8n tool ( n8n get workflow , n8n list workflows , n8n update partial workflow , n8n manage datatable , n8n manage credentials , n8n executions , n8n test workflow , n8n health check , …) takes an optional instance: "<name " . It routes that one call and changes nothing else. Prefer this. Set the default with switch — n8n instances({mode:"switch", name}) sets the instance used by calls that don't name one. The default is shared more widely than it looks. On claude.ai (and other hosted connectors) one connection serves every chat and agent using it, so a switch in one chat moves all the others too — and their next unnamed call silently lands on your instance. A wrong target is usually silent: a read returns the wrong data and a write lands in the wrong place. So name the instance. If the n8n instances tool is not present, the account is single instance: ignore this skill and use the n8n tools directly. Availability. The instance argument needs hosted n8n mcp backend 0.1.120+ / n8n mcp 2.94.0+. It is there when the n8n tools' input schemas list an instance property (and the n8n instances list output carries a hint about it). If it isn't listed, the server predates it: fall back to switch , in its own turn, as described under Switching . Golden rules 1. Discover first. Call n8n instances({mode:"list"}) so you know the exact instance names and which one is current . Never guess a name. 2. Name the instance on every call when it matters — whenever you work on more than one instance, on any instance other than current , or alongside other agents/chats on the same account: n8n list workflows({instance:"prod"}) . Names are case insensitive. Pass the name the same way on every call of the task; there is nothing to "set up" first. 3. An instance you name is never silently replaced. An unknown name fails with INSTANCE NOT FOUND and lists the available names — pick one from that list and retry. It never falls back to another instance. 4. Use switch only to change the default , and only when you're the sole user of the connection. Switch in its own turn — never in the same parallel batch as a call that depends on it (batch order isn't guaranteed). 5. Credential writes: name the instance. n8n manage credentials({action:"create", …, instance:"prod"}) . A named write is explicit, so it is never INSTANCE AMBIGUOUS . Check the name against list first — naming the wrong instance writes the secret there. 6. An unexpected NOT FOUND is almost always a wrong instance misroute, not a deletion. Don't recreate the object. Retry with instance set to where it lives (see Recovery). Core workflow Every call names its target, so it doesn't matter what any other chat switched to in between, and calls can safely run in the same parallel batch even when they target different instances. The instance argument Value: an instance name from n8n instances list ( available[].name ), matched case insensitively. Not the id, not the URL — the same URL can be registered under several names. Scope: routes only the call that carries it. It does not change current or the default for anyone. Omitted (or empty): the call uses the default — the last switch on this connection, or the account default. Fails closed with INSTANCE NOT FOUND (the call never reaches n8n, no quota charged) when: the name matches no instance — the error lists available ; the value isn't a string; multi instance mode is off and the name isn't the one instance the connection reaches. n8n instances itself doesn't take instance — it has its own name argument for switch . The n8n instances tool Two modes ( mode is required and enum validated): {mode:"list"} → { current, default, available, hint } , no side effects. current and default are each one instance { id, name, url, isDefault } (or null ). available is every instance, each with an extra isCurrent boolean. Match by name ; never hard code id . {mode:"switch", name:"<name "} → { previous, current } , and sets the default for calls that don't name an instance. name is case insensitive. Error envelope (from the n8n instances tool) Every error returns { error: "<CODE ", message, … } . The ones you'll actually hit: Code When What to do UNKNOWN INSTANCE switch name matches no instance Pick a name from the available list in the error payload and retry. NAME REQUIRED switch with no name Re call with a name (the error lists the valid ones in available ). MULTI INSTANCE DISABLED multi instance mode is off There's nothing to switch; use the n8n tools directly. The user can enable it at the n8n mcp dashboard. NO SESSION the request has neither an MCP session id nor a credential id A selection has nowhere to land. Reconnect / initialize a session, then switch — or just name the instance on each call. UNKNOWN MODE mode wasn't list / switch Use list or switch . INVALID CONTEXT server side metadata missing A server bug, not your input — report it. Instance names can never be default , current , list , or switch (reserved), so you'll never see an instance literally named after a mode or field. INSTANCE AMBIGUOUS (from the credential write path, not the tool) Returned when you call n8n manage credentials (or an n8n manage agents write) without instance , and the default this call inherited is ambiguous: this session never switched on its own but picked up a switch made elsewhere, pointing at a non default instance. Rather than risk writing a secret to the wrong instance, the server blocks the write (it never reaches n8n, no quota is charged) and returns: Fix: decide which instance you actually want ( lastSelected is the inherited switch, default is the account default) and retry the write with instance:"<that name " . (On a server without the instance argument, run n8n instances({mode:"switch", name:"…"}) on this session, then retry.) How targeting behaves (mental model) A named call goes to the named instance, full stop. It's stateless: it neither reads nor changes the default. An unnamed call goes to the default: the last switch on this connection, else the account default. Who shares the default depends on the client. A hosted connector (claude.ai, and anything that spreads one chat over many MCP sessions) keeps one default per connection , shared by every chat and agent on it. A direct client with a stable MCP session (Claude Code, Cursor) keeps a default per terminal, but can fall back to the connection's last switch after a reconnect. Either way, other work can move your default — that is why rule 2 says to name the instance. A switch persists across reconnects, idle and backend deploys (~24h, the MCP session lifetime). Reads and non credential writes without instance route to the default silently — a misroute produces wrong data or a NOT FOUND , not an error. If the default instance is deleted (the user removes it mid session), unnamed calls silently fall back to the account default — no error. Named calls to a deleted instance fail with INSTANCE NOT FOUND . Switching (only when you need to change the default) Use switch when the user asks to change "the" instance, or on an older server without the instance argument. Never batch the switch with the work that depends on it, and remember it moves every chat sharing the connection. Recovery playbook Symptom What it usually means Do this INSTANCE NOT FOUND The instance name is wrong (typo, guess, or the instance was removed) Pick a name from the error's available list and retry. Never drop instance to "make it work" — that silently runs it on the default. INSTANCE AMBIGUOUS on a credential create/update/delete An unnamed secret write on a session that never chose a target Retry the write with instance:"<target " (the error names lastSelected and default — pick the one you want). Never retry blindly. NOT FOUND for a workflow/datatable/credential you know exists You're pointed at the wrong instance — not that it was deleted Retry with instance set to where it lives (check names with list ). Do not recreate the object. A read returns empty or unfamiliar data An unnamed call went to a default someone else moved, or fell back after your instance was deleted Re run the read with instance:"<name " before drawing conclusions. UNKNOWN INSTANCE on switch The name is wrong Read the available names in the error and switch to one of those. n8n health check reports an instanceName you didn't expect Your unnamed calls are going somewhere else Name the instance on your calls (or switch if you own the connection). n8n health check({instance:"…"}) confirms a name resolves. To confirm where unnamed calls go, read current from n8n instances({mode:"list"}) (primary). n8n health check also returns the resolved instance under details.instanceName , but it can be absent on some paths (legacy/chat), so treat it as a secondary confirmation. Credential operations (highest stakes) Credentials hold live secrets, and a misrouted credential write puts a secret on the wrong instance . So: Name the instance on every credential create/update/delete: n8n manage credentials({action:"create", …, instance:"client a"}) . Take the name from list — a named write to the wrong instance still writes there. Without instance , the write goes to the default, which other chats may have moved. The server only catches the ambiguous case ( INSTANCE AMBIGUOUS ); an unnamed write after someone else's explicit switch goes through to their instance. Credential reads ( action:"list" / "get" / "getSchema" ) don't write a secret, but a read off the wrong instance returns the wrong schema or list — name the instance there too. For the n8n manage credentials tool itself (CRUD shapes, getSchema discovery, never inlining secrets into text fields), see n8n mcp tools expert . Common multi instance task: copy something between instances To recreate a credential or workflow from instance A on instance B: No switching, so nothing can move the target between the read and the write. n8n doesn't return credential secret values, so for a credential the user supplies them again for the create on B. Quick reference See instances: n8n instances({mode:"list"}) → { current, default, available, hint } Target one call: add instance:"<name " to any n8n tool call — preferred Change the default for unnamed calls: n8n instances({mode:"switch", name:"<name "}) , its own turn; shared by every chat on a hosted connection INSTANCE NOT FOUND → use a name from the error's available list INSTANCE AMBIGUOUS (unnamed credential write) → retry with instance:"<target " Unexpected NOT FOUND → retry with the right instance ; do not recreate No instance property in the tool schemas → older server: switch in its own turn, verify current before credential writes Integration with other skills n8n mcp tools expert — owns n8n manage credentials (CRUD + getSchema ) and the rule that secrets go through the credential system, never text fields. This skill adds the "which instance?" layer on top. using n8n mcp skills — the router; consult it for which skill own

n8n-multi-instance