AI agents over MCP

NEXT HMI speaks MCP (Model Context Protocol), so an AI assistant can read and edit a project the same way you would in the editor — add pages, place widgets, wire bindings, add alarms, fill in translations. It is off for writes by default, and you decide per project.

How it fits together

One endpoint covers the whole installation:

http://<manager-host>:8000/mcp

It is served by the manager, the only process that sees every project, so an agent connects once and never reconfigures as projects start, stop or get created. Every tool call names which project it acts on, so one session can work across several.

A project does not need to be running to be edited — the tools work on the files. If the project is running, each write is pushed to the live instance, which re-reads the affected files and broadcasts config_changed, so open operator screens and editor tabs update on their own.

Turn it on

1. Enable writes for the project — on the Manager dashboard, tick MCP enabled on the project's row. Off is the default. With it off, an agent can still read that project; every write is refused.

2. Pair a token — a headless client (an agent runner, a desktop assistant) has no manager session, so it authenticates with a bearer token. Mint one by presenting the device-admin password:

   curl -X POST http://localhost:8000/api/manager/mcp/pair \
     -H 'Content-Type: application/json' \
     -d '{"password":"<device-admin>","projectId":"line-a","access":"write","name":"Claude"}'
   

   The response carries the token once — only its hash is stored. A token is scoped to exactly one project and to read or write; it can never reach another project.

3. Point the client at it — configure your MCP client with the endpoint above and Authorization: Bearer <token>.

Working in a browser that is already signed in to the manager? Then the manager session is enough and no token is needed — you already have that privilege through the dashboard.

Managing tokens

What an agent can do

Edit: pages and their widget trees, widget properties, alarms, translations, variables on a datasource, and assets.

Read only: datasources (connection settings and the browsed tree), components, users (names, groups and enabled state — never credentials), and the widget-schema manifest.

Not at all: starting, stopping, creating or deleting projects. Lifecycle stays an operator action in the dashboard, on purpose.

Destructive operations are two-step — the first call returns a diff to review, and only a second call with confirm: true applies it. Page edits also return a warnings list for advisory problems such as an incomplete binding or a reference to a variable that doesn't exist; the write still succeeds, so it's worth reading them.

The full tool catalog, argument shapes and limits are in the MCP reference.

Before you enable it

• Keep it on a trusted network. The endpoint is plain HTTP unless you've turned on HTTPS. A bearer token crossing an untrusted network is a bearer token someone else can use.
• Grant the narrowest scope that works. A read token for an agent that only answers questions about the project; write only where you want edits.
• Confirmation guards the agent, not you. An agent can chain the dry-run and the confirm in a single turn without asking a human. The MCP toggle is the control that actually stops writes.
• Attribution is best-effort. Writes are labelled with the client's name, but any authenticated caller can set that label, so treat the log as advisory rather than proof.