Skip to main content
Glama

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 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:

uvx nodered-mcp --nodered-url http://localhost:1880

You can also pip install nodered-mcp. To work on the package itself:

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:

nodered-mcp --nodered-url http://localhost:1880

You can point it at the file instead:

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

{
  "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

--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 <container>

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:

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

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

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

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.

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
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

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    B
    maintenance
    Minimal MCP server wrapping the Node-RED admin API, enabling flow management, node installation, and context retrieval via natural language.
    -