The @wp-playground/mcp package, released in March 2026, does something that would have sounded absurd two years ago. You type a natural-language description of a WordPress plugin into Claude Code or Gemini CLI, and an AI agent scaffolds it, installs it into a running WordPress instance, and lets you test it. The WordPress instance runs entirely in your browser. No Docker. No local PHP installation. No MAMP, no XAMPP, no Vagrant. One command to connect, and you're building.
TL;DR
- The
@wp-playground/mcppackage bridges AI coding agents (Claude Code, Gemini CLI) to WordPress Playground via the Model Context Protocol. - Setup is a single CLI command. The MCP server runs locally as a Node.js process and communicates with a Playground instance in your browser over WebSocket.
- Genuinely useful for prototyping plugins, learning WordPress internals, and testing ideas quickly. Not a replacement for your production development environment.
- Key constraints: SQLite instead of MySQL, limited networking, no email testing, no persistent state by default. The browser tab is the server, and refreshing it wipes everything.
Table of contents
- What MCP is and why it matters here
- Setting up the connection
- Building a plugin from a prompt
- What the agent can actually do
- Where it breaks down
- The bigger picture: WordPress core embracing AI tooling
- Key takeaways
What MCP is and why it matters here
The Model Context Protocol is an open standard, originally created by Anthropic in November 2024 and now maintained under the Linux Foundation's Agentic AI Foundation. It standardizes how AI applications connect to external tools and data sources. Think of it as a USB-C port for AI: one protocol, many possible connections. By March 2026, MCP had crossed 97 million monthly SDK downloads and is supported by Anthropic, OpenAI, Google, Microsoft, and Amazon.
The architecture follows a client-server model. The AI application (Claude Code, in this case) is the host. An MCP client inside it communicates with an MCP server that exposes tools, resources, and capabilities. The transport layer uses JSON-RPC 2.0 messages, typically over stdio for local servers.
Why does this matter for WordPress? Because @wp-playground/mcp turns a browser-based WordPress instance into an MCP server. Your AI agent can read files, write files, execute PHP, navigate pages, and manage sites, all through a standardized protocol. The agent doesn't need WordPress-specific logic. It just calls MCP tools.
Setting up the connection
Prerequisites: Node.js 22 or later, and either Claude Code or Gemini CLI installed.
For Claude Code, one command:
claude mcp add --transport stdio --scope user wordpress-playground \
-- npx -y @wp-playground/mcpFor Gemini CLI:
gemini mcp add wordpress-playground npx -y @wp-playground/mcpYou can also add the server manually in your .mcp.json (Claude) or settings.json (Gemini):
{
"mcpServers": {
"wordpress-playground": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@wp-playground/mcp"]
}
}
}When you start a Claude Code session and the MCP server activates, it opens a browser window with WordPress Playground running. The server assigns a random local port at startup and passes it to the browser through a URL parameter. A WebSocket connection links the Node.js MCP server process to the Playground instance. Origin restrictions and token-based authentication prevent other browser tabs or extensions from hijacking the connection.
That's it. No configuration inside Playground itself.
Building a plugin from a prompt
Here is what a typical interaction looks like. You open Claude Code in your terminal and type something like:
"Build a WordPress plugin called Reading Time that calculates and displays estimated reading time above each post. Use 200 words per minute as the default. Add a settings page where the user can change the WPM value."
Claude Code calls the MCP tools to scaffold the plugin files (playground_write_file), execute PHP to activate it (playground_execute_php), and navigate to a post to verify the output (playground_navigate). If something breaks, the agent reads the error, adjusts, and retries. You see it happening in real time: file writes in the terminal, the WordPress site updating in your browser.
The feedback loop is fast. You say "move the reading time below the title instead of above it." The agent edits the plugin file and reloads. No build step. No deploy. The iteration cycle compresses to seconds.
For learning WordPress plugin development, this is a genuine shift. A beginner can describe what they want, see it built, inspect the generated code, and understand how WordPress hooks and filters work by watching them get used in context. It's hands-on in a way that reading documentation alone isn't.
What the agent can actually do
The MCP server exposes 17 tools grouped into four categories.
Site management. playground_list_sites, playground_open_site, playground_save_site, playground_rename_site, playground_get_website_url. The agent can create and switch between multiple WordPress instances.
Filesystem. playground_read_file, playground_write_file, playground_list_files, playground_mkdir, playground_delete_file, playground_delete_directory, playground_file_exists. Full read/write access to the WordPress directory tree.
Code execution. playground_execute_php runs arbitrary PHP inside the WordPress context. playground_request sends HTTP requests to the Playground instance. This is where the real power is: the agent can activate plugins, query the database, call WordPress functions, and verify results.
Navigation. playground_navigate, playground_get_current_url, playground_get_site_info. The agent can navigate the frontend and admin, check what's visible, and act on it.
Combine these and the agent can do meaningful work. Install a plugin from a ZIP URL, change wp_options values via PHP, check if a shortcode renders correctly on the frontend, and report back.
Where it breaks down
This is the section that matters more than the setup guide. WordPress Playground is a remarkable piece of engineering (PHP compiled to WebAssembly via Emscripten, running in a Service Worker that intercepts HTTP requests), but it's a sandbox. Sandboxes have walls.
No MySQL. Playground uses SQLite with the SQLite Database Integration plugin that translates MySQL queries into SQLite dialect. The 2.0 translation layer passes 99% of WordPress unit tests, which is impressive. But if your plugin does something MySQL-specific (stored procedures, MySQL-only functions, complex JOINs that hit SQLite edge cases), it won't surface here. You can build a plugin in Playground, then discover it breaks on a real MySQL database.
Limited networking. Web browsers don't allow WebAssembly code to access the internet directly. Playground can translate wp_safe_remote_get calls into JavaScript fetch() requests, but libcurl, file_get_contents with URLs, and raw socket connections don't work. If your plugin calls an external API, you'll need to test that part separately.
No email. wp_mail() has nowhere to go. There's no SMTP server, no sendmail binary, no mail transport at all. If you're building a plugin that sends notifications, you can scaffold the code but not test the delivery. For context, email deliverability is already one of the trickiest parts of WordPress development.
Ephemeral by default. Refreshing the browser tab destroys the instance. Playground offers a Save button that persists state to IndexedDB, but it's not automatic and still undergoing development. You can lose 20 minutes of work by pressing Cmd+R out of habit.
PHP extension gaps. The WebAssembly build includes the 17 most common extensions (libxml, OpenSSL, mbstring, GD, Intl, zLib, and others), which covers the vast majority of WordPress plugins. But if you need something like imagick, redis, or pthreads, it won't be there.
No WP-CLI. Not all standard WP-CLI commands work in the browser environment. The agent works around this by using playground_execute_php directly, but it means you can't replicate a WP-CLI-based workflow.
For prototyping a settings page, a custom post type, a Gutenberg block, or a REST API endpoint? Playground + MCP works well. For testing database migrations, email flows, external API integrations, or performance under load? You still need a real server.
The bigger picture: WordPress core embracing AI tooling
The Playground MCP server is not an isolated experiment. WordPress core is building AI tooling infrastructure at multiple levels.
The Abilities API, introduced in WordPress 6.9, provides a common interface for AI agents, automation tools, and plugins to interact with WordPress. Each ability has a namespace, typed input/output schemas (JSON Schema draft-04), and permission callbacks. WordPress 7.0 extended this to the client side with two JavaScript packages (@wordpress/abilities and @wordpress/core-abilities), laying the groundwork for browser agents that can discover and execute WordPress capabilities directly.
The MCP Adapter plugin bridges these abilities to the Model Context Protocol. It exposes three tools: mcp-adapter-discover-abilities (list what the site can do), mcp-adapter-get-ability-info (get details), and mcp-adapter-execute-ability (do the thing). This is different from Playground MCP. The Adapter connects to a real, running WordPress installation. It supports STDIO transport for local development and HTTP transport for remote sites.
The direction is clear. WordPress wants AI agents to be first-class consumers of its APIs. The Playground MCP server is the low-friction entry point: disposable, safe, zero configuration. The MCP Adapter is the production path: secure, permissioned, and integrated with whatever WordPress abilities your site exposes. If you wrote about WordPress 7.0's changes without covering the Abilities API, this is the part you missed.
Key takeaways
@wp-playground/mcpconnects AI coding agents to disposable WordPress instances in your browser. Setup is one CLI command. Genuinely useful for prototyping and learning.- The agent can read/write files, execute PHP, navigate pages, and manage sites through 17 MCP tools. The feedback loop between prompt and working code is seconds, not minutes.
- Limitations are real and specific: SQLite instead of MySQL, no outbound networking for
libcurl/file_get_contents, no email, ephemeral state, and a subset of PHP extensions. Know these before you start. - WordPress core is building AI infrastructure at every level: the Abilities API (6.9+), the client-side extension (7.0), and the MCP Adapter for production sites. Playground MCP is the sandbox; the Adapter is the production path.
- This changes how developers learn and prototype WordPress plugins. It does not replace a real development environment for production work. Both things are true.