A WordPress MCP server lets an AI assistant call tools against WordPress instead of you clicking through wp-admin. Almost every guide describes the same shape: install a plugin or adapter on a site you already run, hand the agent a credential, then spend the rest of the article on how to stop it breaking anything.
That is one kind. The other kind does not attach to a site at all. It creates one, hands the agent the URL, and throws it away afterwards.
The difference decides which safety problems you have, so it is worth naming before you pick a server.
Kind one: an agent inside an existing site
This is the category everything ranks for. The server runs on or beside a WordPress install, exposes tools like "create post", "list plugins", "update option", and acts as an authenticated WordPress user.
The official WordPress.org MCP server is a narrow, well-scoped example. It sits at https://wordpress.org/wp-json/mcp/wporg and exposes three tools: validate a readme, check plugin review status, submit a plugin. Its own docs are clear that it is not a shortcut, since submissions "go through the same review as plugins submitted through the web form".
Vendor servers are much wider. They can publish, install plugins, edit users and change settings, which is why the honest ones spend their documentation on recovery rather than prevention.
That framing is correct for what they do. If the agent's only workspace is a client's live site, the useful question really is "how fast can I undo this", not "how do I stop it".
Kind two: an agent with a site of its own
The second category inverts the problem. The agent's first tool call creates a WordPress install, so there is nothing valuable in the environment to protect.
Two implementations exist that we know of.
WordPress Playground's MCP server shipped in March 2026 as @wp-playground/mcp. One command wires it into a coding agent:
claude mcp add --transport stdio --scope user wordpress-playground -- npx -y @wp-playground/mcp
It exposes playground_execute_php, playground_read_file, playground_write_file, playground_navigate and friends against a WordPress running in a browser tab. It is free, official, and the connection never leaves your machine.
It is also WebAssembly, and its own announcement says Playground "uses SQLite instead of MySQL". We wrote about where that starts to bite separately.
SandyWP is the other one. Our MCP server is remote, at https://app.sandywp.com/mcp, and the sandbox it creates is a real containerised WordPress with real MySQL, a real filesystem and a public URL.
What "the agent gets its own site" actually looks like
The connection is scoped OAuth, approved once in a browser, revocable from your account:
claude mcp add --transport http sandywp https://app.sandywp.com/mcp
After that, a prompt like "spin up a WordPress 7.0 sandbox on PHP 8.3, install my plugin, and tell me what's in the debug log" is a sequence of tool calls rather than an afternoon.
The server exposes 69 tools today. The ones that matter most in that loop are sandywp_create_site, sandywp_deploy_plugin, sandywp_magic_login for a one-time wp-admin link, sandywp_read_debug_log, sandywp_switch_php_version, and sandywp_reset_site to return the sandbox to a clean install.
Each tool carries the MCP annotations clients use to decide what to wave through. sandywp_list_sites and sandywp_read_debug_log are marked read-only. sandywp_delete_site and sandywp_reset_site are marked destructive, so a well-behaved client asks you first.
Those annotations matter less here than they would on a production server, which is the point. The worst outcome of a mistaken sandywp_delete_site is that the agent creates another one.
Which one should you connect?
Pick by what the agent is being asked to do, not by which server is better.
Use an existing-site server when the work is genuinely about that site's content or configuration. Publishing a post, auditing options, checking review status: none of that means anything against an empty install.
Use a disposable-site server when the work is code. Reproducing a bug report, testing a plugin against PHP 8.3, checking whether an update breaks activation, giving a reviewer something to click.
Use Playground's when you want zero cost and zero setup and your code does not care about the database engine, and ours when it does, or when the site needs to be reachable by someone who is not you.
There is also an honest middle path worth saying out loud: connect a read-only existing-site server to production, and a disposable one for anything that writes. The agent reads the real state and experiments somewhere it cannot do harm.
What a sandbox MCP server will not do for you
A throwaway site removes the blast radius, not the differences.
It will not reproduce load. If the report is "the site falls over at 200 concurrent users", a sandbox tells you nothing.
It will not reproduce your host. Object caching, edge caching, a WAF, open_basedir, OPcache serving a stale file: all of that lives at the hosting layer and none of it comes along.
It will not reproduce anything bound to your domain. Pro plugin licences, real payment gateways, OAuth callbacks and email deliverability from the production domain all behave differently on a sandbox URL.
And a remote MCP server cannot read files on your computer. If the plugin ZIP you want to deploy is sitting in ~/Downloads, the agent should use the SandyWP CLI in your shell instead, because it can read the file and the remote server cannot.
One more thing that is not a technical limit but matters: if you clone a customer site into a sandbox so an agent can debug it, you have copied their user table. Treat that as the data-handling decision it is.
The security question, honestly
The interesting property of a disposable-site server is not that it is unhackable. It is that prompt injection has somewhere safe to land.
An agent reading a WordPress site's content is reading text written by other people. On a live site, a malicious comment or post that instructs the agent to change a setting is a real problem, which is why the existing-site guides insist on least-privilege users and read-only defaults.
In a sandbox, the same injection succeeds and costs you nothing, because the environment was disposable before it started. That does not make the agent trustworthy. It makes the consequences cheap, and cheap consequences are what let you actually use the thing.
The credential still matters. Our OAuth connection is scoped to your SandyWP account, so an agent that goes wrong can create and delete sandboxes, which is a bounded amount of damage, and you can revoke the connection.
Getting started
If you want to try the disposable-site shape, the shortest path is the one command above, then a prompt. Our AI page has the connection details for other clients, and the AI development page covers the workflow around it.
If you find yourself creating the same environment repeatedly, Blueprints turn it into a file the agent can apply, which is a better answer than a longer prompt.
And if the agent's job is really about your live site's content, use one of the existing-site servers. We do not sell that, and pretending a sandbox solves it would waste your afternoon.
