The WordPress Playground team released the @wp-playground/mcp package, which turns the browser environment into a programmable sandbox. Through the Model Context Protocol (MCP) you can wire AI coding agents to WordPress Playground so they read files, execute PHP and change the database with no clicking on your part. That changes how local development and automated testing actually run.
I have written before about WordPress Playground permanent instances, so my bias toward zero-config dev environments is on record. The bottleneck was always the manual part: telling the AI what to fix, then pasting its code into the browser. This bridge removes that step.
How the MCP bridge works
The architecture is simple. The MCP server runs as a local Node.js process over stdio transport, with no cloud middleware in between. Your AI client, Claude Code or Gemini CLI, talks to that server, and the server forwards commands to the Playground instance in your browser over a WebSocket.
When you open Playground, the URL carries an mcp-port parameter. The server handles authentication and origin restrictions so only your local agent can touch the site. It turns natural language requests into concrete tool calls: playground_execute_php, playground_write_file, playground_request.
Quick setup for Claude and Gemini
One command wires it in. For Claude Code:
claude mcp add --transport stdio --scope user wordpress-playground -- npx -y @wp-playground/mcpIf you already work inside the Model Context Protocol tooling, that standard transport means your agent picks up the WordPress filesystem and the PHP runtime as available tools right away.
Practical workflows for AI coding agents in WordPress Playground
The trouble with a normal AI assistant is that it cannot check its own answer, so it guesses. With this bridge it can verify. Three uses that have already saved me hours:
1. Headless plugin installation and testing
No more downloading zips by hand. You tell the agent: “Install WooCommerce and confirm the ‘Store’ page is created.” It runs activate_plugin() through playground_execute_php, then fires a playground_request to see what the front end returned.
2. Debugging wp_options with SQL
Hunting through the admin UI for a stale transient or a broken setting is wasted time. I would rather query the database. An agent can read options through $wpdb like this:
<?php
global $wpdb;
$bbioon_results = $wpdb->get_results(
"SELECT option_name, option_value FROM $wpdb->options
WHERE option_name LIKE '%rewrite_rules%'"
);
print_r($bbioon_results);Playground runs on SQLite and $wpdb handles the translation, so the result lands in your terminal instead of phpMyAdmin.
3. Scaffolding boilerplate
Most of a child theme is directory busywork. Prompt it instead: “Scaffold a child theme for Twenty Twenty-Five with a custom header.php.” The agent builds the structure with playground_mkdir and playground_write_file, then activates it to see whether anything fatals.
I covered AI agent skills in an earlier post. This MCP package is the piece that was missing for browser-based automation.
If wiring AI coding agents into WordPress Playground is eating your dev hours, I can take it on. I have been wrestling with WordPress since the 4.x days.
What this changes in practice
Less of the work is typing code and more of it is directing the tools that type it. Connecting your AI client straight to WordPress Playground takes the manual testing loop out of that shift. The @wp-playground/mcp package is on NPM if you want to point it at your own plugin.
