The npx bridge is how most desktop AI clients reach a self-hosted WordPress MCP server. It is a small Node process your client starts on your own machine: it speaks MCP over stdio to the client, and HTTPS to your site. Nothing is installed permanently, and nothing routes through anyone else’s cloud.
Free plugin · No account · Runs on your own server · Any WordPress host
Command
npx -y @automattic/mcp-wordpress-remote@latest
Environment
WP_API_URL · WP_API_USERNAME · WP_API_PASSWORD
Transport
stdio to the client, HTTPS to your site
Before you start
You need AcrossAI MCP Manager installed and active on the WordPress site you want to reach, plus an administrator account on that site. The official WordPress MCP Adapter ships bundled inside the plugin, so there is nothing separate to install on the server. If you have not done that yet, follow the Get Started guide first.
On the machine running your AI client you need Node.js. npx ships with npm, which ships with Node, so if node -v prints a version you already have everything the bridge needs. Any currently supported release is fine — the bridge has no build step and no global install.
How to configure the npx bridge
Step 1
Understand what the bridge actually does
Most desktop AI clients launch their MCP servers as local commands and exchange messages with them over standard input and output. Your WordPress site speaks MCP over HTTPS, at a REST route. The bridge is the adapter between the two: the client runs npx, npx runs @automattic/mcp-wordpress-remote, and that process forwards each MCP message to /wp-json/acrossai/mcp on your domain with your Application Password attached.
The bridge is not a daemon and not a service. It exists only while the client session is open, it opens no listening port, and it holds no state of its own. Close the client and the process is gone.
Step 2
Find out where npx lives
Open a terminal and run the three commands below. The first two confirm Node and npx are installed; the third prints the absolute path you may need in step 3.
node -v
npx -v
which npx # Windows: where npxIf which npx returns something under .nvm, .fnm, .asdf or .volta, your Node is managed by a version manager that sets itself up in your shell profile. A GUI application started from the Dock, the Start menu or Spotlight never reads that profile, so it will not find npx by name. Keep the path — step 3 shows where it goes.
A path such as /usr/local/bin/npx or /opt/homebrew/bin/npx is stable. A path with a version number in it, such as /Users/you/.nvm/versions/node/v22.11.0/bin/npx, stops existing the day you remove that Node version.
Step 3
Write the bridge into your client’s MCP config
Every client keeps this in a different place — ~/.cursor/mcp.json, claude_desktop_config.json, .vscode/mcp.json, ~/.codex/config.toml — and under a different top-level key. The entry itself is the same everywhere: a command, its arguments, and an environment block. Run Quick Connect under AcrossAI → MCP in wp-admin and it generates this for your client with your real site URL and username already in place.
"your-site-mcp-adapter-default-server": {
"command": "npx",
"args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
"env": {
"WP_API_URL": "https://example.com/wp-json/acrossai/mcp",
"WP_API_USERNAME": "your-wp-username",
"WP_API_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx"
}
}Four things in that block are worth knowing. -y answers npx’s “install this package?” prompt automatically — without it the bridge waits for an answer at a terminal the client does not have, and the client reports a timeout. The server key is <site-slug>-<last URL segment>, which keeps two sites distinguishable when you connect more than one. WP_API_URL is the full endpoint, not just the domain. And WP_API_PASSWORD is an Application Password, never your login password.
If step 2 showed a version-manager path, replace the bare "npx" with that whole path — "command": "/Users/you/.nvm/versions/node/v22.11.0/bin/npx". And if you would rather the bridge never change under you, drop @latest and name a version instead: "@automattic/mcp-wordpress-remote@0.2.9".
Application Passwords are shown once, at creation. Copy the value whole, including the spaces — WordPress accepts them. If you lose it, generate a new one rather than trying to recover it.
Step 4
Restart the client and watch the first run
Restart the client fully so it re-reads its config. The first start is the slow one: npx downloads the package into your npm cache before the bridge can answer anything, which on a cold cache can take several seconds. Every start after that reuses the cached copy and is near-instant. Ask something harmless to confirm the connection is live — “Which plugins on this site need updating?” is a good first test.
If it does not connect, run the same command yourself in a terminal with the same three environment variables set. The bridge starts in the foreground and waits for MCP messages on stdin, so a bad URL or a rejected password surfaces there instead of being swallowed by the client.
What your client can do once the bridge is connected
With Abilities Manager installed alongside MCP Manager, the bridge exposes 350+ abilities across 14 toolsets — rising past 800 once it detects the plugins you already run. Whichever client is on the other end of the stdio pipe, it can:
- Read and edit content — posts, pages and any custom post type with their meta and revisions, and surgically edit a page’s block tree without rewriting the page.
- Debug a broken site — read the debug log with secrets redacted, check Site Health, list recent fatal errors and un-pause what WordPress auto-disabled.
- Inspect the database — schema and table sizes, index health, bloated autoloaded options, or
EXPLAINon a slow query. - Manage plugins, themes and core — search WordPress.org, install, update, roll back, and verify files against official checksums.
- Work with files — inside an allowlist you define, with a dangerous-extension blocklist and optional pre-image backups of everything it touches.
- Reach the plugins you already run — WooCommerce, Elementor, ACF, Rank Math, Yoast, WPCode and more, each registering only when that plugin is active.
The bridge adds no permissions of its own. Every ability runs WordPress’s own capability check for the user whose Application Password is in the config, so the AI can never do anything that account could not already do. See the full platform overview for the complete catalogue.
Frequently asked questions
Does npx install anything on my machine?
Not in the sense of a global install. npx downloads the package into your npm cache the first time it runs it, then reuses that copy. There is no entry in your global package list, nothing on your PATH, and nothing to uninstall later — clearing the npm cache removes it entirely.
Should I use @latest or pin a version?
@latest is the right default for a single workstation: you pick up fixes without touching the config. Pin an exact version — @automattic/mcp-wordpress-remote@0.2.9 — when the config is shared across a team, committed to a repository, or running somewhere you cannot easily debug. A pinned version is reproducible; @latest can change between two restarts on the same day.
Does my site data pass through AcrossAI or npm?
No. npm serves the package file and is out of the picture once it is cached. From then on the bridge runs on your machine and connects straight to your own domain — no relay, no gateway, no account, no telemetry. Whatever the AI reads is still processed by that AI’s provider, so treat it as you would any other prompt.
Can I point one bridge at several sites?
One bridge process serves one site, because the credentials live in its environment block. To reach several sites, add one entry per site with its own key — staging-mcp-adapter-default-server, live-mcp-adapter-default-server — and its own Application Password. The client starts one process per entry.
Is the bridge a security hole on my machine?
It opens no listening port and accepts nothing from the network — it only reads stdin from the client that started it. The credentials it carries sit in a plain-text config file, so treat that file as you would an SSH key, and revoke the Application Password from your WordPress profile if the machine is lost. Access is re-checked on every request, so revoking takes effect immediately.
Troubleshooting
spawn npx ENOENT or “command not found”
The client cannot see npx on its PATH. This is almost always a version manager: nvm, fnm, asdf and Volta install themselves into your shell profile, and a GUI application launched from the Dock, the Start menu or Spotlight never reads that profile. Run which npx in a terminal and put the whole path in command.
Remember that an nvm path contains the Node version, so it breaks the day you remove that version. If you switch Node often, install a system or Homebrew Node as well and point the config at its stable path instead.
It worked yesterday and the bridge behaves differently today
@latest re-resolves against the registry, so a new release can arrive between two restarts without you changing anything. Pin the version you know works — "args": ["-y", "@automattic/mcp-wordpress-remote@0.2.9"] — and raise it deliberately.
If the behaviour change is on the WordPress side rather than the bridge, check the server’s access rules instead: access is re-checked on every request, so a change to your role or capabilities takes effect immediately even though the config is untouched.
self-signed certificate in certificate chain
Local development sites — Local, Laragon, DDEV, Valet and similar — serve HTTPS with a certificate Node does not trust, and the bridge refuses the connection. For a local site only, add "NODE_TLS_REJECT_UNAUTHORIZED": "0" to the env block alongside the three WP_API_* variables.
That switch disables certificate verification for the whole Node process, which means the bridge would accept an intercepted connection without complaint. Never set it on an entry whose WP_API_URL points at a production domain, and never pair it with an Application Password for a live site. If you want the connection verified locally instead, trust your development tool’s root certificate in the system store and leave the switch out.
The first connection times out, later ones work
npx fetches the package before the bridge can answer the client’s handshake, and on a cold npm cache or a slow connection that download can outlast the client’s startup timeout. Run npx -y @automattic/mcp-wordpress-remote@latest once in a terminal to warm the cache, press Ctrl-C when it starts waiting for input, then restart the client.
A corporate proxy or an offline machine produces the same symptom permanently. Check npm ping resolves before assuming the bridge is at fault.
The bridge connects but there are no tools, or requests are refused
An empty tool list means the connection works and the catalogue is empty: either Abilities Manager is not installed, or the abilities are not exposed to this server. Open AcrossAI → MCP, select the server, and check its Tools and Abilities tabs — then restart the client, because MCP clients receive their tool list once, at connection time.
Requests that are refused rather than empty point at access rules. A new server requires manage_options until you add a rule, and the gate fails closed. If authentication itself fails, generate a fresh Application Password from Quick Connect — they are shown once and are not your login password — and confirm WP_API_URL is the full endpoint, ending in /wp-json/acrossai/mcp, not just the domain.
Clients that use the npx bridge
The bridge is the same in every one of these guides — only the config file and its top-level key change. See Cursor, Claude Desktop, Claude Code, VS Code, GitHub Copilot, Windsurf, Zed, Codex and every other client.
Not installed yet?
Install MCP Manager on your site, then come back and run Quick Connect.