Connect an AI client to your WordPress site over WP-CLI (STDIO). Your client launches wp as a subprocess on the same machine as the site and talks to it over standard input and output. There is no URL, no Application Password and no network hop — the credentials problem disappears because nothing ever crosses the network.
Free plugin · No account · Runs on your own server · Any WordPress host
Config file
Your client’s own mcp.json
Top-level key
mcpServers
Command
wp mcp-adapter serve
Before you start
You need three things on one machine: WP-CLI installed, the WordPress install itself, and a shell account allowed to run wp against it. On the site, AcrossAI MCP Manager must be installed and active — the official WordPress MCP Adapter ships bundled inside it, so there is nothing separate to install. MCP Manager needs WordPress 7.0 or later; Abilities Manager needs 6.9 or later; both need PHP 8.1 or later. If you have not installed them yet, follow the Get Started guide first.
Understand the trade-off before you commit to it. STDIO works by starting a child process, so it cannot reach a remote site: your AI client and your WordPress files have to share a filesystem. That makes it the strongest option for local development and for a server you already have shell access to, and no option at all for a site you only reach over HTTPS. For anything remote, use the npx bridge instead.
How to connect WP-CLI (STDIO) to WordPress
Step 1
Confirm WP-CLI can see your site
From a shell on the machine hosting the site, point WP-CLI at the WordPress root and ask it for a version. If it answers, everything else on this page will work.
wp core version --path=/var/www/example.comNote the exact --path you used and keep it — the AI client will start wp from its own working directory, not yours, so the path has to be spelled out in full. wp --info shows which PHP binary WP-CLI is using; it must be 8.1 or later.
Step 2
List the MCP servers WP-CLI can serve
MCP Manager registers its servers into WordPress, and WP-CLI reads the same registry. Ask it what is there, and note the ID of the server you want to expose.
wp mcp-adapter list --path=/var/www/example.comThis guide uses the recommended AcrossAI server, acrossai-mcp-server — the same one served over HTTP at /wp-json/acrossai/mcp. Any server in the list works: pass its slug to --server. The table also shows how many tools, resources and prompts each server carries, which is the quickest way to tell a configured server from an empty one.
If the list is empty, MCP Manager is not active on the install that --path points at. You can edit which toolsets a server exposes at any time under AcrossAI → MCP.
Step 3
Add wp mcp-adapter serve to your client’s config
Open your client’s MCP config file — ~/.cursor/mcp.json for Cursor, claude_desktop_config.json for Claude Desktop, ~/.codeium/windsurf/mcp_config.json for Windsurf — and add the entry below under mcpServers. There is no env block and no password, because there is no request to authenticate.
{
"mcpServers": {
"your-site-mcp-adapter-default-server": {
"command": "wp",
"args": [
"mcp-adapter",
"serve",
"--server=acrossai-mcp-server",
"--path=/var/www/example.com",
"--user=admin"
]
}
}
}Three arguments matter. --server picks which registered server to expose, and defaults to the first one if you leave it out. --path is not optional in practice: the client starts wp from wherever it happens to be, so WordPress will not be found without it. --user decides whose WordPress account the session runs as — every ability is then checked against that user’s capabilities. Omit it and the process runs unauthenticated, with correspondingly little it is allowed to do.
If you already have other MCP servers configured, add this one alongside them rather than replacing the file. Clients that use a different top-level key — servers in VS Code, context_servers in Zed — take the same command and args; see the MCP JSON reference for the exact shape each one expects.
Step 4
Restart the client and check the tools
Restart your client so it reads the new configuration and starts the subprocess. Your site should appear as an MCP server, and the toolsets it exposes become available in chat. Ask something harmless to confirm it is live — “Which plugins on this site need updating?” is a good first test.
A newly created server requires manage_options until you add an access rule to it, and the gate fails closed — so a request refused on a fresh server usually means the account named in --user is not an administrator. Access rules live under AcrossAI → MCP, and the Quick Connect wizard there generates configuration for HTTP clients if you need one later.
What WP-CLI (STDIO) can do once it is connected
With Abilities Manager installed alongside it, the STDIO session reaches 350+ abilities across 14 toolsets — rising past 800 once it detects the plugins you already run. The catalogue is identical to the one served over HTTP; only the pipe is different. From your editor or terminal, your client 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.
Every ability runs WordPress’s own capability check for the user named in --user, so the client can never do anything that account could not already do from wp-admin. See the full platform overview for the complete catalogue.
Frequently asked questions
Do I need an Application Password for this?
No. Application Passwords exist to authenticate an HTTP request, and STDIO makes no HTTP request. The subprocess is already inside WordPress; the only things standing in for a credential are the shell account allowed to run wp and the --user flag that names the WordPress account to act as. Nothing secret is written into the config file, which makes it safe to commit a project-level MCP config to a repository.
Can I point this at a remote site?
No. STDIO is a local pipe between two processes on one machine, so the client has to be able to launch wp against your WordPress files directly. It is ideal for local development and for a server you are already logged into over SSH; it is the wrong tool for a site you only reach over HTTPS, and for most managed hosting where you have no shell at all. Use the npx bridge for those.
Does my site data pass through AcrossAI servers?
No. There is no relay, no gateway and no telemetry — over STDIO the data does not even leave the machine on the way out of WordPress. Be clear about the other half of the journey, though: whatever your client reads is still sent onward to its own AI provider for processing, exactly as any other prompt would be. STDIO removes the network hop to your site, not the one to the model.
Can the client break my site?
Every ability runs WordPress’s own capability check for the user named in --user, so the session can never exceed what that account can already do. Higher-risk operations refuse to run without an explicit confirmation flag, file access is confined to an allowlist you define, search-and-replace is a dry run by default, and any ability can be disallowed site-wide. If you want a smaller blast radius, point --user at an editor rather than an administrator.
How do I disconnect again?
Remove the entry from your client’s config file and restart it. There is no password to revoke, because none was ever issued. If you want to cut access without touching the client, change the role of the account named in --user, or remove the server’s access rule: access is re-checked on every request, so it takes effect immediately even while a session is open.
Troubleshooting
The client says the server failed to start, but the command works in my shell
This is the usual first failure, and it is almost always the environment rather than the command. A desktop client does not inherit your shell’s PATH, so "command": "wp" resolves to nothing — run which wp and use the absolute path, typically /usr/local/bin/wp. It also does not inherit your shell’s working directory, which is why --path has to be an absolute path to the WordPress root. If WP-CLI is installed through a version manager, or your site needs environment variables set in .zshrc, add them to an env block on the server entry — the subprocess will not see them otherwise.
The client reports invalid JSON, or the connection drops on the first request
Over STDIO, standard output is the protocol: it must carry newline-delimited JSON-RPC and nothing else. A PHP notice, a deprecation warning, a var_dump() left in a theme, or any plugin that echoes during load will be interleaved into the stream and the client will reject the message. The bridge deliberately writes its own diagnostics to standard error to keep stdout clean, so anything else on stdout came from your site. Run wp mcp-adapter serve --path=… by hand and watch the first lines: if you see anything that is not JSON, fix that first. Turning off WP_DEBUG_DISPLAY resolves most cases.
wp mcp-adapter is not a registered command
The command is registered by the MCP Adapter, which loads with MCP Manager — so this means the plugin is not active on the install --path points at. Confirm with wp plugin list --status=active --path=/var/www/example.com. On a multisite, add --url= as well, since which plugins are active depends on the site being addressed.
It connects, but there are no tools — or every call is refused
An empty tool list means the connection works and the catalogue does not. Either Abilities Manager is not installed — MCP Manager will serve an empty catalogue quite happily — or the abilities exist but are not exposed to this server. wp mcp-adapter list shows the tool count per server, which settles it in one command. Calls that are refused rather than missing are an access problem instead: a new server requires manage_options until a rule is added and the gate fails closed, and a session started without --user is unauthenticated. After changing what a server exposes, restart the client — MCP clients receive their tool list once, at connection time.
It exits with “The STDIO transport is disabled”
STDIO can be switched off at the site, and something on this install has done so — the mcp_adapter_enable_stdio_transport filter is returning false. Look for it in a custom plugin, a snippet manager or your theme’s functions file. On a shared or client-managed server that may well be deliberate, in which case connect over the npx bridge instead.
Connect a different AI client
Any MCP client that can launch a subprocess can use the configuration above — and for a remote site, the same clients take the npx bridge instead, with only the config file and top-level key changing. See the guides for Claude Desktop, Claude Code, Cursor, VS Code, GitHub Copilot, Windsurf, Zed, Codex and every other client.
Not installed yet?
Install MCP Manager on your site, then run wp mcp-adapter list to see your servers.