@builderius/sense-ai

Live editing for the Builderius website builder: an MCP server that lets an AI coding agent build and edit templates in a builder tab you have open.

Requires Node 20+ and a Builderius Pro licence.

How it works

Builderius' editing API only exists inside the browser, so there is no server an agent can call. The builder page therefore dials out to this connector over a WebSocket, and the connector relays commands into it.

your agent  ──stdio MCP──▶  sense mcp
                              │  POST 127.0.0.1:7681/builder-command
                              ▼
                     whoever holds the port
                              │  ws://127.0.0.1:7681/builder
                              ▼
                  the Builderius builder in your browser

One port carries every builder bridge on the machine. If Clockheart Desktop is running it already holds that port, and this connector simply attaches to it and holds no socket of its own. If nothing is there, it starts its own bridge. It never quietly moves to a different port — the builder reads its port from a WordPress setting, so a connector that relocated would be one nothing can reach.

Use

Add it to your agent as an MCP server, run from the WordPress root:

{
  "mcpServers": {
    "builderius": {
      "command": "npx",
      "args": ["-y", "@builderius/sense-ai", "mcp", "--port=7681"],
      "env": {
        "WP_API_URL": "https://example.com",
        "WP_API_USERNAME": "your-wp-username",
        "WP_API_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx"
      }
    }
  }
}

All three, not just the password. The builder page authenticates with a short-lived token the site derives from its own salt, not with your password, so the connector has to exchange the password for that same token — and it needs the site and the username to have something to exchange with. Given the password alone it falls back to sending the password itself, which the bridge cannot match against the page, and the symptom is no builderius page is connected while a page is demonstrably connected.

The password goes in this config, next to the server that uses it — not in a file on the side. Create it in WordPress under Builderius → Settings → Sense AI → Live editing (or Users → Profile → Application Passwords) and paste it here. --port must match the port on that same screen.

WORDPRESS_API_URL, WORDPRESS_API_USERNAME and WORDPRESS_API_PASSWORD are still read as older spellings of the same three.

Starting the bridge is part of starting the MCP server, so there is nothing else to run. To drive it by hand instead:

npx -y @builderius/sense-ai serve      # run the bridge in the foreground
npx -y @builderius/sense-ai status     # what is on the port, if anything
npx -y @builderius/sense-ai tabs       # which builder pages are connected

Then open a Builderius template. In WordPress, Builderius → Live editing must be on, and its port must match.

Local HTTPS development sites

A certificate every browser on the machine accepts — Herd, Valet, Local, DDEV, mkcert — is still rejected by Node, which does not read the OS trust store. The symptom is not a certificate error: the token exchange fails, the connector falls back to a credential the builder page cannot match, and every command reports that no builder page is connected while one plainly is.

On a name that can only be this machine — localhost, loopback, *.test, *.localhost, *.local, *.ddev.site — this package handles it and says so on stderr. Nothing to configure.

Anywhere else, point Node at the CA your tool installed, in the same env block: "NODE_EXTRA_CA_CERTS": "/path/to/local-CA.pem" (Valet and Herd: ~/.config/valet/CA/LaravelValetCASelfSigned.pem; mkcert: rootCA.pem inside mkcert -CAROOT). Restart the MCP server afterwards.

Not NODE_OPTIONS. --use-system-ca is not one of the flags Node accepts through that variable, so "NODE_OPTIONS": "--use-system-ca" does not merely fail to help — Node refuses to start at all and the MCP server never comes up.

Several builder pages open at once

A command goes to exactly one page, never all of them. Broadcasting looks harmless and is how a build corrupts itself: each page runs the command against its own store and mints its own ids, so two pages will happily create two different things under one name.

Which page, in order:

1. A command that names an entity goes to the page holding that document. Builderius keeps several templates open behind one connection, so a template in a background tab still routes there.
2. A command that names a tab goes to exactly that page.
3. Reads whose answer is the same everywhere (listTabs, getCssFramework, getBreakpoints, …) go to any page.
4. Otherwise the focused page wins — the one you were looking at when you typed. Once a run has picked a page it stays there, so a long build does not follow you between windows.
5. If several pages are open and none has ever reported focus, the command is refused with the tab ids to retry with. Run sense tabs to see them.

Credentials

The credential is your WordPress Application Password — the same secret WordPress REST Basic Auth accepts, so one credential covers this connector and any WordPress MCP tools. WordPress owns it: revoke it under Users → Profile and it stops working everywhere.

The builder page gets it from WordPress itself. This MCP server reads it from its own config, via WP_API_PASSWORD in the env block above, alongside WP_API_URL and WP_API_USERNAME — that is the supported way, and it keeps the secret with the server that uses it rather than in a stray file.

A .auth-token file in the working directory still works as a fallback for setups that predate this, one site per line, mode 0600. Nothing writes it any more; prefer the config.

The bridge cannot verify a credential against WordPress — it knows neither the site URL nor the username — so it either trusts a list you configure with --token, or adopts the first credential it sees and announces it. That is acceptable because everything binds 127.0.0.1 on a machine you control; it is not a boundary against other software already running as you.

Security

Loopback only. Do not expose the port. The connector executes whatever commands an MCP client sends into your builder, so treat access to the port as equivalent to access to the builder.