WordPress Playground MCP is out, and it solves one specific annoyance: telling an AI agent what is actually inside your WordPress install. If you use Claude Code or Gemini CLI, you know the routine. You copy a chunk of a file into the chat, paste the error back, repeat. The @wp-playground/mcp package cuts that loop by wiring the agent to a Playground instance over the Model Context Protocol (MCP).
Once it is running, the agent can read files, execute PHP and change site options in the browser tab you already have open. From its side, the Playground instance looks like any other local environment.
How the bridge works
The MCP server is a local Node.js process talking over stdio. Your AI client sends commands to that process, which relays them to your browser tab through a WebSocket. Nothing leaves your machine, and the server still checks the request origin and a token before it accepts anything.
For Claude Code, one command registers the server:
claude mcp add --transport stdio --scope user wordpress-playground -- npx -y @wp-playground/mcpGemini CLI takes about the same amount of setup. Either way, the agent picks a random local port and links it to the Playground tab with a URL parameter. That opens the door to WordPress AI agent skills that were too fiddly to automate before.
Practical workflows with WordPress Playground MCP
With the bridge up, the agent stops being a text generator and starts being a junior dev who can check its own work. Two ways I have been using it.
1. Automated plugin testing
Instead of downloading zips and clicking through the admin UI, you tell the agent to install a plugin and check it. It calls playground_execute_php to fetch the files and activate_plugin() to switch it on, then reports back whether the plugin broke the block editor or collided with something else.
2. Digging through the database
Say you want to know what WooCommerce has stashed in wp_options. You do not need an SQL client for that. Ask the agent for the autoloaded options you care about and it runs something like this, printing the result straight into the chat:
<?php
function bbioon_debug_options() {
global $wpdb;
$results = $wpdb->get_results(
"SELECT option_name, option_value FROM $wpdb->options
WHERE option_name LIKE '%woocommerce%'"
);
return $results;
}
print_r(bbioon_debug_options());One caveat: Playground runs on SQLite, so MySQL-only syntax will bite you. The $wpdb layer is still in place though, so ordinary queries behave. Being able to poke around like this is most of the value during a long debugging session.
If this WordPress Playground MCP setup is eating your dev hours, hand it over to me. I have been wrestling with WordPress since the 4.x days.
A new standard for AI workflows
The @wp-playground/mcp package is on NPM and speaks the Model Context Protocol, the same protocol the rest of the AI tooling world has settled on. In practice that means an agent can drive WordPress without a custom adapter per client, and two people on the same project end up debugging the same environment.
If you want to suggest new tools for the filesystem or site management, or write one yourself, the official WordPress Playground docs are the place to start.
