nodered-mcp
Click on "Deploy 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., "@nodered-mcpCheck for orphaned nodes in my flows"
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.
nodered-mcp
An MCP server for Node-RED. Read, edit, and deploy your flows from an MCP client.
About
This server lets an MCP client work with a Node-RED instance: tabs, nodes, wires, groups, subflows, and config nodes. It can read them, edit them, and deploy the result to the running instance.
It connects to Node-RED through the Admin API, or reads and writes a
flows.json file directly. Either way, the tools understand the Node-RED
format. They can tell a flow node from a config node, follow a wire across
tabs, and size a group box the same way the editor does.
Related MCP server: nr-mcp
Features
Reading. List tabs, groups, subflows, orphaned nodes, and config nodes along with what references them. Search by name, type, or tab. Trace a wire from node to node.
Editing nodes. Create, update, rename, duplicate, and delete nodes. Enable and disable them. Wire and unwire them, insert one into an existing wire, or bypass one so traffic routes around it.
Editing groups and tabs. Create, populate, restyle, and delete groups. Create, rename, reorder, and delete tabs. Import and export sets of nodes.
Layout. Ask for a free region before placing nodes, so you do not have to guess coordinates. Check the canvas for overlapping nodes and groups, fix them, and repack a tab's groups into columns.
Batching. Edits stay in memory until you save or deploy, so a build with many nodes lands as a single change. Use
diffto see what will change, andundoto step back one call at a time.Safety checks. A layout gate blocks any write that creates a new overlap. A staleness check blocks any write that would overwrite a deploy someone made from the browser while you were working.
Requirements
Python 3.11 or newer. The only dependency is
fastmcp.Either a reachable Node-RED, or a
flows.jsonon this filesystem.
Docker is only needed for the fallback deploy route. You can ignore it if Node-RED's Admin API is reachable.
Installation
You do not need to install anything. uvx will fetch and run it:
uvx nodered-mcp --nodered-url http://localhost:1880You can also pip install nodered-mcp. To work on the package itself:
git clone https://github.com/ljmerza/nodered-mcp
cd nodered-mcp
uv syncUsage
The server needs to know where your flows are. The simplest option is to point it at a running Node-RED, which reads them over the Admin API. Node-RED can be on another machine:
nodered-mcp --nodered-url http://localhost:1880You can point it at the file instead:
nodered-mcp --flows-path /path/to/nodered/data/flows.jsonIf you give it neither, it looks in ~/.node-red/ and uses the flow file it
finds. This helps with a normal npm install -g node-red, which names the file
after your hostname (flows_raspberrypi.json). Only the Docker image calls it
flows.json.
Register with an MCP client
{
"mcpServers": {
"nodered": {
"type": "stdio",
"command": "uvx",
"args": ["nodered-mcp"],
"env": {
"NODERED_URL": "http://localhost:1880"
}
}
}
}See .mcp.json.example for a fuller example.
Configuration
Each setting can come from a CLI flag, an environment variable, or a default, in that order of priority.
Flag | Environment variable | Default | Purpose |
|
| (unset) | Base URL of the running Node-RED. Reads flows and deploys over its Admin API |
|
| (discovered) | Path to |
|
| (unset) | Admin API token, if |
|
|
| Only expose the read tools |
|
| (editor theme) | JSON merged over Node-RED's default style for new groups |
|
|
|
|
|
|
| Bind address for |
These only apply to the fallback deploy route described below:
Flag | Environment variable | Default | Purpose |
|
|
| Container name used by |
|
|
| Path to |
|
|
| Restart command. |
Where the flows come from
If you set --nodered-url, the server reads your flows with GET /flows and
writes them back with POST /flows. It needs no filesystem access, so it works
the same way against a container, a systemd service, a Home Assistant add-on,
or a machine across the network.
Node-RED assigns a revision to each version of the flows. The server sends back
the revision it loaded, so if someone else deploys while you are working,
Node-RED returns a 409 and your edit is refused instead of overwriting their
work. You can override this with session(op='deploy', force=true).
If you set --flows-path instead, the server reads the file. The equivalent
check compares the file against what was loaded, which catches a deploy from
the browser the same way.
Group styling
Groups created by this server carry no colors, which is what Node-RED itself does. The editor calculates the stroke and fill from the current theme, so a group looks correct whether the person viewing it uses the light or dark theme.
If you want a specific look, set the keys you care about:
NODERED_GROUP_STYLE='{"fill": "#2e333a", "fill-opacity": "0.75"}'Read-only mode
--read-only removes nodered_edit, nodered_group, and nodered_tab from
the tool list entirely, so a client never sees them. It also refuses the
editing operations of the other two tools. This is useful if you want to point
a model at a production Node-RED to ask questions about it.
How deploy reaches Node-RED
save only writes flows.json. Node-RED reads that file when it starts and
not again, so saving on its own does not change anything in the running
instance. If there is no local file, save has nothing to do and will tell you
so. deploy is what makes your flows live, and it has two routes.
Admin API, used when you set --nodered-url. The flows are sent to
Node-RED's Admin API, the same endpoint
the editor uses when you press Deploy. Node-RED swaps them in place, so there
is no restart and no downtime, and this machine needs no container runtime. If
you also configured a local flows.json, it is written first so the file stays
in sync.
Your node credentials are not affected. They live in flows_cred.json, keyed
by node id, and a deploy that carries no credentials leaves them alone. This
was tested against Node-RED 5.0.4.
If your settings.js sets httpAdminRoot, include it in the URL
(http://localhost:1880/admin). If it enables adminAuth, you will need a
token. Node-RED creates one from your editor credentials, and it expires after
7 days by default:
curl -s http://localhost:1880/auth/token \
--data 'client_id=node-red-admin&grant_type=password&scope=*&username=admin&password=secret'
# {"access_token":"...","expires_in":604800,"token_type":"Bearer"}
NODERED_TOKEN="..."Docker, used when you do not set --nodered-url. The server copies the
flows into the container with docker cp and then runs --restart-cmd. This
restarts the whole container and needs the Docker CLI plus socket access. Point
--restart-cmd at whatever manages the container:
NODERED_RESTART_CMD="docker compose restart {container}"Run session(op='status') to see which route is configured.
Tools
There are eight tools. Each one takes an op argument that selects what it
does.
Tool | Ops |
|
|
| Structured search by tab, type, or name substring |
| One node's raw JSON plus its wiring context |
|
|
|
|
|
|
|
|
|
|
A typical build
nodered_query(op="tabs") -> tab ids
nodered_layout(op="free_region", tab_id=TAB, w=800, h=200) -> {"x": 100, "y": 3240}
nodered_edit(op="create_node", tab_id=TAB, node_type="inject",
name="tick", x=100, y=3240) -> node id
nodered_edit(op="create_node", tab_id=TAB, node_type="switch",
name="gate", x=300, y=3240) -> node id
nodered_edit(op="wire", source_id=..., target_id=...)
nodered_group(op="create", name="My Flow", tab_id=TAB, node_ids=[...])
nodered_session(op="save")Everything above stays in memory until that final save.
Arranging a tab
Tabs tend to grow into one tall column over time, because each new flow gets
added below everything else. arrange repacks them.
nodered_layout(op="audit") -> worst tabs first
nodered_layout(op="arrange", tab_id=TAB) -> the plan, nothing moved
nodered_layout(op="arrange", tab_id=TAB, apply=true) -> groups repacked
nodered_session(op="save")Groups get packed into columns, each one going into whichever column is
currently shortest. The server picks a column count that brings the tab's
overall shape closest to target_ratio, which defaults to 1.6 (roughly a
widescreen viewport). You can pass columns to set it yourself. The sort
argument controls placement order: packed puts the tallest first and packs
most densely but reorders the tab, current keeps the existing reading order,
and name sorts alphabetically.
Nodes that do not belong to a group are never moved. If the packed block would land on one of them, the whole block drops below instead. A tab with a scratch node parked in the middle will arrange around it.
arrange is a dry run unless you pass apply=true. It reports the footprint
it will produce beforehand, and it can be undone like any other edit.
Decoupling groups
When a wire runs from a node in one group to a node in another, the two groups
are tied together. Moving one stretches the wire across the tab, so you cannot
arrange them independently. decouple replaces each of those wires with a
link out and link in pair, so the wire ends at the edge of its own group
and resumes inside the other one.
nodered_group(op="decouple", tab_id=TAB) -> the crossings, nothing changed
nodered_group(op="decouple", tab_id=TAB, apply=true) -> one link pair per crossing
nodered_layout(op="arrange", tab_id=TAB, apply=true) -> now safe to repack
nodered_session(op="save")You get one pair per wire, named after the node at the other end (-> compute,
tick ->). The link out goes in a column just right of the source group's
nodes, and the link in just left of the target group's, so each group grows by
one column no matter how many wires cross it. Both boxes are resized
afterwards.
Two kinds of wire are skipped. Wires touching an ungrouped node are left alone, because there is no second group to decouple from. So are wires between a group and its own parent or child, because those already move together.
Use tab_id to scope it to a whole tab, or group_id for just the crossings
that touch one group. Like arrange, it is a dry run unless you pass
apply=true, and it can be undone. Widening the boxes can push a group into a
neighbor, which the layout gate would block when you save, so the operation
reports any overlap it creates and arrange can repack them.
How it protects your flows
The layout gate
save and deploy check the canvas before and after your edit. If the edit
introduces a new error-level problem, the write is refused.
Finding | Severity | Meaning |
| error | A group box landed on another group box |
| error | A group box no longer covers its own nodes |
| warning | A node sits inside a group box it is not a member of |
| warning | Two nodes occupy the same space |
Problems that were already there do not block anything. Only new ones do. When the gate fires, the fix is usually one of these:
nodered_layout(op="free_region")to claim clear canvas, then place therenodered_group(op="refit", group_id=...)to resize a group around its nodesnodered_session(op="save", allow_overlap=true)if the overlap is deliberate
Group geometry is exact, because the sizing rules come from the Node-RED editor, so a computed box matches what the editor draws. Node geometry is exact except for label text width, which is estimated from Helvetica metrics. That is why node-level findings are only ever warnings.
The staleness check
If someone presses Deploy in the browser while you have edits pending, your commit would silently undo their work. Both sources guard against this, using whatever the source can verify.
With the Admin API, Node-RED assigns a revision to every version of the
flows. The server sends back the revision it loaded, and Node-RED returns a
409 if that is no longer current. Because Node-RED performs the check itself,
nothing can slip in between the check and the write.
With a file, the server records the modification time and size when it loads, then checks again before every write. It uses nanosecond precision, because a float timestamp only resolves to about a microsecond and a write landing in the same tick as the load would look identical. If the timestamp does not match, the server compares the file's actual contents before calling it a conflict. A rewrite that produces the same flows you already have is not someone else's work: after a deploy, Node-RED saves those same flows back to the file with a new timestamp.
In both cases the commit is refused rather than overwriting the other change.
You can either reload and redo your edits, or pass force=true.
Standalone use
Both engine modules work as libraries and as CLIs, without MCP.
uv run python -m nodered_mcp.flows summary --flows-path /path/to/flows.json
uv run python -m nodered_mcp.layout --path /path/to/flows.json --fix boxes,movefrom nodered_mcp.flows import Flows
f = Flows("/path/to/flows.json")
ox, oy = f.free_region(tab_id, w=1600, h=300)
f.create_node(tab_id, "inject", "tick", x=ox, y=oy)
f.save()Running
--fix boxeson its own makes things worse. Refitting grows some boxes so that they swallow neighboring nodes that are not members. Runboxes,movetogether, and read the dry run before passing--apply.
Project layout
src/nodered_mcp/
├── server.py FastMCP server: the eight tools
├── session.py in-memory session, stdout capture, staleness guard
├── config.py CLI flags and environment resolution
├── flows.py the Flows class, composed from the mixins below
├── constants.py defaults, group style, and the exception types
├── reports.py ReadMixin — summary, tab, group, search, trace
├── nodes.py NodeEditMixin — create/update/delete/wire nodes
├── groups.py GroupMixin — create, populate, and delete group boxes
├── tabs.py TabMixin — create, rename, reorder, and delete tabs
├── placement.py LayoutMixin — claim free canvas, refit boxes, arrange tabs
├── transfer.py TransferMixin — import and export node sets
├── persist.py PersistMixin — save, deploy, and the layout gate
└── layout.py canvas geometry and linter, ported from the NR editorFlows composes those mixins, so the public API stays flat: f.summary(),
f.create_node(), f.free_region(), f.save().
Development
uv sync --group dev
uv run pytest
uv run ruff check .
uv run ruff format --check .Tests run against a synthetic fixture in tests/fixtures/, never a real flows
file. They cover configuration precedence, the read tools, the
in-memory-until-save behavior, the layout gate both blocking and overridden,
both staleness guards, both deploy routes, and read-only mode. One test checks
that no tool writes to stdout, because a stray print would corrupt the MCP
stdio framing.
CI runs the same checks through
ljmerza/misc-actions.
Contributing
Issues and pull requests are welcome. Please keep ruff check, ruff format,
and pytest green.
Acknowledgments
Node-RED: the canvas geometry here is ported from its editor client, so group boxes match what the editor draws.
FastMCP: the MCP server framework.
License
MIT. See LICENSE.
This server cannot be deployed
Maintenance
Related MCP Connectors
Create, browse, remix, collaborate on, and run durable AI workflow nodes from MCP hosts.
Render, verify, describe, and safely edit Mermaid diagrams through MCP.
List, read, edit, and deploy your GenMB AI-generated apps from any MCP client.
n8n MCP — query your own n8n instance (BYO).
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables management of multiple N8N workflow automation instances through MCP. Supports listing, creating, updating, deleting, executing workflows and monitoring their executions across different N8N environments.59MIT
- AlicenseAqualityDmaintenanceLets AI assistants interact with Node-RED to read flows, search nodes, edit function code, deploy changes safely, and manage modules.131MIT
- AlicenseNot gradedqualityBmaintenanceExposes Node-RED flows as MCP tools for AI assistants, with OAuth protection and optional admin tools for flow management.411ISC
- FlicenseNot gradedqualityBmaintenanceMinimal MCP server wrapping the Node-RED admin API, enabling flow management, node installation, and context retrieval via natural language.-