WordPress just became the first CMS with official MCP server support baked into its core announcements. Two separate tools landed this week from the WordPress project: a WordPress Playground MCP server that lets AI coding agents spin up and control sandboxed WordPress instances, and a Plugin Directory MCP server that gives agents direct access to the wordpress.org plugin repository. Together, they change what AI-assisted WordPress development actually looks like in practice.
This is a hands-on guide. You will come out of it with both MCP servers running in your editor, understanding what they can do, and a clear picture of where they fit into a real WordPress development workflow. No AI hype, just setup, capabilities, and honest limitations.
What Is WordPress Playground, and Why Does MCP Matter Here?
WordPress Playground is an in-browser WordPress runtime, a full WordPress installation that runs entirely in WebAssembly in your browser, with no server required. You can load it at playground.wordpress.net and have a working WordPress admin in seconds. It resets on page refresh, making it perfect for disposable testing environments: try a plugin without installing it on your real site, test a code change in isolation, or reproduce a bug with a clean install.
For developers, Playground has been most useful for plugin compatibility testing and demo environments. The gap has always been automation: you had to interact with it manually through the browser UI. If you wanted to test a plugin in twenty different WordPress and PHP version combinations, you were clicking through twenty browser sessions.
MCP, the Model Context Protocol, changes this by giving AI coding agents a structured interface to control external systems. When WordPress Playground exposes an MCP server, an AI agent in your editor can programmatically spin up Playground instances, install plugins, run WP-CLI commands, and read back results, all in response to natural language instructions. Your AI assistant goes from answering questions about your code to actually testing it.
The Two WordPress MCP Servers Explained
1. WordPress Playground MCP Server
The Playground MCP server exposes WordPress Playground as a tool-callable interface. An AI agent connected to it can:
- Create a fresh WordPress instance (specify WP version, PHP version)
- Install and activate plugins from the Plugin Directory or from local paths
- Apply blueprints, Playground’s JSON configuration format for reproducible environments
- Run WP-CLI commands against the Playground instance
- Read the state of posts, settings, user accounts, and installed plugins
- Check for PHP errors and JavaScript console output
- Take screenshots of the WordPress frontend or admin
For a plugin developer, this means you can ask your AI coding assistant “test this plugin against WordPress 6.6 with PHP 8.1” and it will actually do it, spin up the environment, install the plugin, run activation, check for errors, and report back. That is a workflow shift, not just a convenience improvement.
2. WordPress Plugin Directory MCP Server
The Plugin Directory MCP server gives AI agents access to the wordpress.org plugin repository data. An agent can:
- Search plugins by keyword or category
- Retrieve plugin metadata: active installs, ratings, last updated date, tested-up-to version
- Check plugin compatibility with a specific WordPress version
- Read plugin readme files and changelogs
- Find plugins by author or tag
This matters because AI models do not have current knowledge of the plugin ecosystem. Without the Plugin Directory MCP server, an AI assistant recommending a plugin is drawing on training data that may be a year or more out of date, and cannot verify whether a plugin is still actively maintained or compatible with your WordPress version. With the MCP server, the agent can check against live data before making a recommendation.
Setup: Adding Both MCP Servers to Claude Code
Claude Code stores MCP server configuration in its settings file. On macOS, this is at ~/.claude/claude_code_config.json (or ~/.claude/settings.json depending on your version). Add both WordPress MCP servers to the mcpServers object:
After adding the configuration, restart Claude Code. On next launch it will run npx -y @wp-playground/mcp-server and npx -y @wordpress/plugin-directory-mcp as child processes, the -y flag auto-confirms the npx install on first run. You should see both servers listed in the Claude Code MCP status panel.
Verifying the Connection
Once restarted, ask Claude Code: “List the available WordPress Playground tools.” A successful connection returns a list of tool names like playground_create, playground_install_plugin, playground_run_cli, and playground_screenshot. If you get an error instead, check that Node.js 18+ is installed and that npx is on your PATH (which npx in Terminal should return a path).
Setup: Adding Both MCP Servers to Cursor
Cursor stores MCP configuration in .cursor/mcp.json at the project level (for project-scoped servers) or in your global Cursor settings for workspace-wide availability. The format is the same as Claude Code:
In Cursor, go to Settings → Features → MCP to see connected servers and their status. The same Node.js 18+ requirement applies. VS Code with the Copilot extension also supports MCP via its mcp.json configuration, the format is nearly identical to the Cursor config above.
What You Can Actually Do: Real Workflows
Setup is the easy part. Here is where the combination of Playground MCP and Plugin Directory MCP changes your actual development workflow.
Workflow 1: Testing a Plugin Against Multiple Environments
The classic use case. You have a plugin and want to verify it works across WordPress 6.5, 6.6, and 6.7 with PHP 8.1 and 8.2. Previously: six browser sessions, six manual installs, six sets of results to read. With Playground MCP, you describe the matrix to your AI assistant and it runs through each combination, reporting back errors, deprecation notices, and PHP warnings from each environment.
The key is the blueprint format. A Playground blueprint is a JSON document that specifies the WordPress version, PHP version, and a list of setup steps (install plugins, activate themes, create users, import content). The agent can generate and apply blueprints programmatically, you describe what you want the environment to look like, it creates it.
Workflow 2: Plugin Compatibility Research Before Installation
Ask the Plugin Directory MCP server before installing anything: “Find me a membership plugin that is compatible with WordPress 7.0, has more than 10,000 active installs, and was updated in the last three months.” The agent queries the repository against those parameters and gives you a filtered list, with current data, not training data.
Then take it further: “Install the top result in a Playground instance with WordPress 7.0 and PHP 8.2 and tell me if it activates without errors.” The agent hands off from the Plugin Directory MCP server to the Playground MCP server, fetching the plugin, installing it in a sandbox, and checking for activation errors. You get a real compatibility test, not an educated guess.
Workflow 3: Debugging Plugin Conflicts
Plugin conflicts are notoriously hard to reproduce. You have a live site with forty plugins installed, and something is broken. The debugging question is: which combination is causing it?
With Playground MCP, you can run a binary search against plugin combinations. Ask the agent to create a Playground instance with your plugin and suspected conflict plugins, enable them in different combinations, and test the specific interaction that is failing. What used to take hours of enabling and disabling on a staging site can be parallelized across multiple Playground instances in minutes.
Workflow 4: Automated Plugin Review
Before adopting a new plugin in a client project, there is usually a manual evaluation: install it, poke around the settings, check the output HTML, verify it does not conflict with existing plugins. This can be scripted through Playground MCP. Give your AI assistant a plugin slug and a checklist, it installs the plugin in a representative Playground environment, activates it, checks the frontend output for issues, and produces a structured compatibility report.
Workflow 5: Reproducing User-Reported Issues Without a Staging Server
When a user reports a bug, you usually need a clean environment to reproduce it before you can fix it. Historically that meant either risking reproduction on your live site or spinning up a staging server. Playground MCP eliminates both: describe the reported environment to your AI assistant (“user is on WordPress 6.6, PHP 8.0, with WooCommerce 9.x active”), ask it to create a matching Playground instance, and reproduce the issue there. The full reproduction cycle, environment setup, plugin install, issue trigger, takes minutes rather than the better part of an hour. Once reproduced, you can test fixes in the same instance before touching any deployed code.
Workflow 6: Writing Better CLAUDE.md Context for WordPress Projects
If you use Claude Code for WordPress development, you can now include Playground-specific context in your CLAUDE.md file, preferred PHP version, blueprint configuration, testing notes. This tells the AI assistant exactly how to set up a test environment for your project without you having to repeat it every session:
With this in place, asking “test this change in Playground” automatically uses the correct environment configuration, you are not specifying PHP versions or blueprint steps every time.
Playground MCP and WordPress 7.0’s Native MCP Support
It is worth being clear about the distinction between two things that are easy to conflate:
- WordPress Playground MCP server, a tool that exposes the Playground sandbox environment to AI agents. Runs outside of WordPress itself.
- WordPress 7.0 native MCP server support, a feature landing in WordPress 7.0 that exposes a live WordPress installation’s data (posts, users, settings, plugins) to AI agents via MCP.
These are complementary, not duplicates. The Playground MCP server is for development and testing, throwaway sandboxes. The WordPress 7.0 MCP server is for production sites and real data. When both are connected to your AI assistant simultaneously, you get the full picture: query real site data through the WordPress 7.0 MCP server, then spin up a matching environment in Playground to test changes safely before deploying.
If you are already using Claude’s large context window for WordPress development, layering in both MCP servers is the natural next step. The context window gives you breadth, the whole codebase in view at once. The MCP servers give you actuality, real site data and real test environments rather than static code analysis alone.
Honest Limitations
MCP enthusiasm tends to outrun MCP reality in early coverage. Here is what the WordPress Playground and Plugin Directory MCP servers cannot do, or do poorly right now.
Playground Is Not a Performance Test Environment
WordPress Playground runs in WebAssembly, it is not representative of server performance. Testing whether a plugin causes a fatal error in PHP 8.2 is valid. Testing whether a plugin adds 200ms to page load on a VPS is not. Do not draw performance conclusions from Playground test results.
Plugin Directory Data Has a Lag
The Plugin Directory MCP server reads from the wordpress.org API, which is updated periodically rather than in real time. A plugin updated yesterday may not reflect in the MCP server’s response immediately. For broad compatibility and install count checks, this is fine. For “was this plugin updated in the last 24 hours” level decisions, check directly on wordpress.org.
Agent Reliability Varies by Task Complexity
Simple tasks, “install this plugin in a fresh WordPress install and check for activation errors”, are reliable. Complex multi-step tasks, “run a full end-to-end test of this checkout flow across three plugin configurations”, produce less consistent results. The agent can lose track of state, apply steps out of order, or misinterpret intermediate results. Treat complex Playground automation as assisted testing, not fully automated testing. Review the agent’s work output before acting on it.
npx Latency on First Run
Because both MCP servers are installed via npx -y, the first run involves a package download that can take 15–30 seconds. Subsequent runs use the npx cache and are fast. If your first attempt to use a Playground tool times out, it is likely the initial package install, try again and it will be cached.
No Persistent Storage Across Playground Sessions
Each Playground instance created through the MCP server is ephemeral, it does not persist data between sessions unless you explicitly export state. If you are building up a test environment over multiple agent interactions, and the Playground session resets (due to timeout or restart), you start from scratch. Blueprint-driven setup (as covered above) is how you make this less painful, the blueprint recreates the environment deterministically each time.
Practical Tips for Getting the Most Out of These Tools
Use Blueprints for Reproducible Environments
Do not ask the agent to build up an environment step by step across multiple messages. Write a blueprint that captures the full environment configuration and ask the agent to apply it as a single step. This is faster, more reliable, and means you can re-run the same setup later without reconstructing the conversation history.
Scope Plugin Directory Queries Precisely
“Find me a good form plugin” returns too many results to be useful. “Find me form plugins with 100,000+ active installs, tested with WordPress 7.0, last updated within six months, and compatible with PHP 8.2” gives the agent parameters to filter against. Precise queries produce useful answers; vague queries produce long lists you have to evaluate manually anyway.
Combine with Your Existing CLAUDE.md Workflow
If you maintain a CLAUDE.md file in your WordPress project (you should, see the Claude Code developer workflow guide), add your standard Playground configuration to it. This means any new Claude Code session on your project automatically knows how to set up the test environment without you specifying it.
Keep Your npx Cache Warm
Both MCP servers start via npx, which means they download on first use and cache locally. On slow connections or corporate networks with npm restrictions, this first-run download can fail or time out and silently break the MCP server startup. Run npx -y @wp-playground/mcp-server --version and npx -y @wordpress/plugin-directory-mcp --version manually once to warm the cache and verify both packages install cleanly before relying on them inside your editor. This avoids discovering a network issue in the middle of a development session.
Run Playground Tests Before Filing Bug Reports
Before filing a bug report against a plugin you use, reproduce the issue in a clean Playground environment first. This answers two questions immediately: is the issue reproducible in a clean install (eliminating your local environment as the cause), and which WordPress / PHP version combination triggers it? A bug report with “reproduced in clean Playground on WordPress 6.7, PHP 8.2” is far more actionable than “it broke on my site.”
How This Fits Into the WordPress 7.0 AI Picture
WordPress 7.0 is arriving with multiple parallel AI integration tracks: the native MCP server (live site data for AI agents), AI agent integration (authorized agents taking actions on WordPress), and now the Playground MCP server and Plugin Directory MCP server (sandboxed testing and repository access). These are not competing features, they compose into a coherent developer workflow.
A WordPress developer’s AI-augmented workflow in the post-7.0 world looks something like this: the AI coding assistant has live context about the production site (via the WordPress 7.0 MCP server), can test code changes safely (via the Playground MCP server), can evaluate plugin options with current data (via the Plugin Directory MCP server), and can read the full codebase at once (via the large context window). Each capability addresses a different limitation of AI assistance, together, they reduce the gap between “AI suggests a solution” and “solution is verified correct and safe.”
The tooling is early. The ergonomics are rough in places. The workflows described in this guide work, but they require some tolerance for iteration, you will learn what prompting patterns produce reliable results and which ones do not. That is the current state of MCP-connected AI development across the board, not just WordPress. The underlying capability is real; the tooling will improve quickly.
Getting Started Checklist
- Verify Node.js 18+ is installed:
node --version - Add both MCP server configs to your editor (Claude Code or Cursor)
- Restart your editor and verify both MCP servers appear as connected
- Test with a simple prompt: “Create a WordPress 6.7 Playground instance and tell me the installed plugins”
- Test Plugin Directory: “Find the top three BuddyPress-compatible form plugins tested with WordPress 7.0”
- Add Playground configuration to your CLAUDE.md for your active WordPress projects
- Try a real use case: install your current active plugin in a Playground instance and check for PHP 8.2 deprecation notices
Frequently Asked Questions
Does the Playground MCP server require a wordpress.com account?
No. The Playground MCP server runs locally via npx, it has no dependency on a wordpress.com account. The Plugin Directory MCP server queries the public wordpress.org API, also without authentication. Both work entirely offline except for the initial npx package download and Plugin Directory API calls.
Can I test premium or private plugins through Playground MCP?
Yes. The Playground MCP server can install plugins from local paths, not just from the Plugin Directory. If you have a premium plugin as a zip file on your local machine, you can ask the agent to install it from that path. The Plugin Directory MCP server only covers the free wordpress.org directory, it has no access to premium marketplaces.
Is this the same as WordPress Playground’s built-in “Open in Playground” feature?
The “Open in Playground” browser button uses WordPress Playground’s browser-based runtime directly. The MCP server is a separate tool that exposes a programmatic interface to Playground, it is not the same code path, and it is designed for agent-driven automation rather than direct user interaction in the browser.
What WordPress versions are available in Playground?
WordPress Playground supports multiple WordPress versions including 6.4, 6.5, 6.6, 6.7, and latest. PHP versions include 7.4, 8.0, 8.1, 8.2, and 8.3. You can specify both in your blueprint configuration. The Playground team updates version availability as new WordPress releases ship.
Can I use these MCP servers with AI tools other than Claude Code and Cursor?
Any MCP-compatible AI coding tool can connect to these servers. GitHub Copilot, Windsurf, Continue.dev, and other editors with MCP support follow the same configuration pattern, check your specific tool’s MCP documentation for where to place the configuration file. The server packages themselves (@wp-playground/mcp-server and @wordpress/plugin-directory-mcp) are editor-agnostic.
No comments yet