# 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.
## 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 `diff` to see what will change, and
`undo` to 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.json` on 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:
```bash
uvx nodered-mcp --nodered-url http://localhost:1880
```
You can also `pip install nodered-mcp`. To work on the package itself:
```bash
git clone https://github.com/ljmerza/nodered-mcp
cd nodered-mcp
uv sync
```
## Usage
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:
```bash
nodered-mcp --nodered-url http://localhost:1880
```
You can point it at the file instead:
```bash
nodered-mcp --flows-path /path/to/nodered/data/flows.json
```
If 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
```json
{
"mcpServers": {
"nodered": {
"type": "stdio",
"command": "uvx",
"args": ["nodered-mcp"],
"env": {
"NODERED_URL": "http://localhost:1880"
}
}
}
}
```
See [`.mcp.json.example`](.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 |
|---|---|---|---|
| `--nodered-url` | `NODERED_URL` | *(unset)* | Base URL of the running Node-RED. Reads flows and deploys over its Admin API |
| `--flows-path` | `NODERED_FLOWS_PATH` | *(discovered)* | Path to `flows.json`. Optional when `--nodered-url` is set |
| `--nodered-token` | `NODERED_TOKEN` | *(unset)* | Admin API token, if `adminAuth` is enabled |
| `--read-only` | `NODERED_READ_ONLY` | `false` | Only expose the read tools |
| `--group-style` | `NODERED_GROUP_STYLE` | *(editor theme)* | JSON merged over Node-RED's default style for new groups |
| `--transport` | `NODERED_MCP_TRANSPORT` | `stdio` | `stdio`, `http`, or `sse` |
| `--host` / `--port` | `NODERED_MCP_HOST` / `NODERED_MCP_PORT` | `127.0.0.1` / `8080` | Bind address for `http` and `sse` |
These only apply to the fallback deploy route described below:
| Flag | Environment variable | Default | Purpose |
|---|---|---|---|
| `--container` | `NODERED_CONTAINER` | `nodered` | Container name used by `deploy` |
| `--container-flows-path` | `NODERED_CONTAINER_FLOWS_PATH` | `/data/flows.json` | Path to `flows.json` inside the container |
| `--restart-cmd` | `NODERED_RESTART_CMD` | `docker restart ` | Restart command. `{container}` is substituted |
### 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:
```bash
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](https://nodered.org/docs/api/admin/), 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:
```bash
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:
```bash
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 |
|---|---|
| `nodered_query` | `summary`, `tabs`, `groups`, `tab`, `group`, `search`, `ungrouped`, `orphans`, `subflows`, `styles`, `configs`, `entities`, `inspect`, `connections`, `trace` |
| `nodered_find_nodes` | Structured search by tab, type, or name substring |
| `nodered_get_node` | One node's raw JSON plus its wiring context |
| `nodered_edit` | `create_node`, `create_config_node`, `update_node`, `update_many`, `delete_node`, `rename_node`, `set_enabled`, `duplicate_node`, `replace_node`, `wire`, `unwire`, `insert_between`, `bypass`, `import_nodes`, `export_group` |
| `nodered_group` | `create`, `add`, `move_node`, `delete`, `rename`, `set_style`, `normalize_styles`, `refit`, `shift`, `bounds`, `decouple` |
| `nodered_tab` | `create`, `rename`, `delete`, `reorder`, `set_enabled`, `set_info` |
| `nodered_layout` | `check`, `audit`, `free_region`, `occupied`, `arrange`, `fix` |
| `nodered_session` | `status`, `diff`, `undo`, `save`, `deploy`, `reload` |
### A typical build
```text
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.
```text
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.
```text
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 |
|---|---|---|
| `group-overlap` | error | A group box landed on another group box |
| `group-escape` | error | A group box no longer covers its own nodes |
| `stray-in-group` | warning | A node sits inside a group box it is not a member of |
| `node-overlap` | 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 there
- `nodered_group(op="refit", group_id=...)` to resize a group around its nodes
- `nodered_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.
```bash
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,move
```
```python
from 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 boxes` on its own makes things worse. Refitting grows some
> boxes so that they swallow neighboring nodes that are not members. Run
> `boxes,move` together, 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 editor
```
`Flows` composes those mixins, so the public API stays flat: `f.summary()`,
`f.create_node()`, `f.free_region()`, `f.save()`.
## Development
```bash
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`](https://github.com/ljmerza/misc-actions).
## Contributing
Issues and pull requests are welcome. Please keep `ruff check`, `ruff format`,
and `pytest` green.
## Acknowledgments
- [Node-RED](https://nodered.org): the canvas geometry here is ported from its
editor client, so group boxes match what the editor draws.
- [FastMCP](https://gofastmcp.com): the MCP server framework.
## License
MIT. See [`LICENSE`](LICENSE).