MCP Servers for WordPress Developers: The Tools I Actually Use Every Day

I run a WordPress product business with over 100 plugins. Every day involves debugging support tickets, shipping fixes, reviewing code, and managing releases. Until about six months ago, all of that required constant context-switching, browser to terminal to IDE to phpMyAdmin to GitHub and back again.

MCP servers changed that. Not by making Claude smarter, but by giving Claude access to my actual systems, so instead of describing what is in my database, I ask Claude to check it. Instead of pasting code from three files, Claude reads them directly. Instead of manually pushing to GitHub after a fix, Claude creates the PR. The context-switching is the expensive part of software development work, not in API costs, but in cognitive load. MCP servers eliminate most of it.

This is my actual setup. Every MCP server I describe here is running right now and I use it daily across my 100+ plugin workflow.

What MCP Is and Why It Matters for WordPress Developers

Model Context Protocol is a standard that lets Claude connect to external tools. Each MCP server exposes a set of actions Claude can call, read a file, query a database, make an API call, control a browser. You configure which servers to run in ~/.claude/mcp_servers.json, and Claude uses them automatically when they are relevant to what you ask.

For WordPress developers specifically, this matters because our work is inherently data-heavy. We are constantly checking what is in the database, what a PHP function does in a specific file, what changed between plugin versions, whether a staging site produces the right output. Without MCP, all of that requires manual copying between windows. With MCP, it happens inside the conversation. The difference is not marginal, it is the difference between Claude being a writing assistant and Claude being an actual collaborator in your development environment.

The other thing that MCP enables is chain-of-tool reasoning. Claude can read a file, check a database value, and open a PR, without you orchestrating each step. That composition is where the real leverage comes from, and I will show a concrete example of it below.

My Full MCP Stack

I run 19 MCP servers across three categories. What follows is not a theoretical list, these are the servers I actually have running right now, with honest notes on which ones get daily use and which I reach for less often.

Core Development Servers

Filesystem MCP (@modelcontextprotocol/server-filesystem) gives Claude read/write access to my Local Sites folder and plugin repositories. This is how Claude reads plugin code without me pasting it, edits multiple files in one conversation, and understands full plugin architecture instead of just the fragment I show it. I scope it tightly, only my WordPress development directory, not my home folder. This is the first server anyone should set up. Everything else builds on the assumption that Claude can see your actual files.

GitHub MCP (@modelcontextprotocol/server-github) closes the loop from fix to PR. After Claude proposes a fix, it creates the branch, commits the change, and opens the pull request, all in the same conversation. I use fine-grained personal access tokens scoped to specific repositories. The key thing this eliminates: the time between “the fix is done” and “the fix is on GitHub” used to require multiple manual steps. Now it is one instruction.

Me: Fix looks good. Create branch fix/hashtag-mobile, commit to js/autocomplete.js,
    open a PR against main describing what broke and the fix.

Claude: PR created: github.com/wbcomdesigns/buddypress-hashtags/pull/147

Fetch MCP (@modelcontextprotocol/server-fetch) fetches any public URL as readable text. I use it to read WooCommerce or BuddyPress hook documentation, check WordPress.org plugin pages, and read API docs without copy-paste. It also works for reading changelog entries from external plugins to understand breaking changes.

Playwright MCP (@playwright/mcp) gives Claude control of a real browser. I describe a test scenario in plain language and Claude runs it, navigates, logs in, interacts, screenshots the result. I never write Playwright test scripts. When a customer reports a visual bug, this lets me reproduce and verify the fix without leaving the conversation.

WordPress-Specific Custom MCP Servers

These are the servers where the setup becomes genuinely specialized for WordPress work. Three of the four required building custom servers, which is a half-day of work per server, but each one eliminates a class of friction that used to cost me more time than that every single week.

mcp-local-wp connects directly to MySQL databases of my Local by Flywheel installs via socket. I ask Claude to check what is in wp_options, verify a transient is being set correctly, confirm user meta keys, or query BuddyPress activity meta, all without opening phpMyAdmin. The time savings on debugging are real: most database-layer issues take less than a minute to rule out or confirm now.

Me: Check wp_options for bp_hashtags_settings. Also check for _transient entries with that prefix.

Claude: Found bp_hashtags_settings: a:3:{s:12:"enable_links";b:1;...}
        Value looks valid. Found _transient_bp_hashtags_cache_12 (expires 2h).
        Settings are saving correctly, issue is in retrieval, not storage.

Fifteen seconds to rule out the database layer. That used to take five minutes through phpMyAdmin, and it required knowing exactly where to look. Claude figures out where to look from the context of what you are debugging.

wp-site-doctor handles SSH-based operations on production and staging sites, error log inspection, cache flushing, remote WP-CLI commands, and health checks. When a customer reports a live site issue, I check the error log directly without needing to open a terminal, navigate to the right log path, and tail the file. The server wraps all of that into a single readable action.

wp-malware-cleanup handles security scanning for client sites, malware pattern scanning, hidden admin user detection, core file integrity verification, and wp-config hardening. This is more specialized work, but having it as an MCP means I can run a security audit as part of a support investigation rather than as a separate dedicated session.

wp-plugin-qa runs structured plugin audits before releases, covering UI, API, database, accessibility, and browser compatibility. Before every major plugin release, I run this audit and address the findings. It catches things that are easy to miss when you have been staring at the same code for weeks.

Content, Project, and Analytics Servers

wp-blog is my custom MCP for managing WordPress content across 10 sites. It creates Gutenberg block posts, handles the publishing workflow (SEO check, word count, internal links, featured image), manages the content calendar, integrates with Google Search Console, and runs SpyFu keyword research. This post was published through it. The server enforces publishing standards automatically, minimum word count, SEO score threshold, internal links, which keeps content quality consistent without requiring manual checklists.

basecamp gives full access to my project management. When a customer reports a bug, Claude can create the Basecamp card, assign it, and add the support context, all in one action. The card has the right information in it from the start, which saves whoever picks it up from having to go back to the ticket to understand the context.

automem provides persistent memory across Claude sessions. It stores facts about plugins, customer patterns, architectural decisions, and anything that should carry forward between conversations. Without this, every session starts cold and I repeat context unnecessarily. For plugins I work on infrequently, having stored memory means I do not need to re-read the architecture docs at the start of every session.

analytics-mcp connects to Google Analytics 4. I pull traffic data, check content performance, or compare metrics across sites without opening GA4. Useful when someone asks about a plugin’s documentation traffic or when I want to correlate a release with a traffic change.

content-trends monitors Reddit, Hacker News, dev.to, GitHub trending, and tech news for topics relevant to WordPress development and my content sites. I use this for content planning, what are developers actually asking about that I have not written about yet.

context7 fetches up-to-date library documentation for npm packages and frameworks, useful for block development where I need current React or @wordpress/blocks API docs without leaving the conversation.

How These Servers Chain Together on a Real Bug

Here is a real debugging session from last week, which illustrates how the chain-of-tool reasoning works in practice. The report: activity search returns no results for hashtag searches after updating to version 1.4.2.

GitHub MCP: Show every file changed between v1.4.1 and v1.4.2, filtered to search-related classes. This takes about 10 seconds and gives Claude the diff to work from.
Filesystem MCP: Read class-search.php and compare the query logic to what the git diff shows was there before the update. Claude identifies the changed meta_query structure immediately.
mcp-local-wp: Query the buddypress-dev database, do activity_meta rows exist for recent hashtag activity? Confirms the data is there but the query is not finding it.
Playwright MCP: Open buddypress-dev.local, log in as admin, run an activity search for “testing”, screenshot the result. Visual confirmation of the bug exactly as the customer reported it.
Filesystem + GitHub MCP: Apply the fix, create branch fix/hashtag-search-meta-query, commit, open PR.

Total time: 18 minutes from bug report to open PR. Without these MCPs, the same session would have been 75-90 minutes of manual work, and some of it would have been guesswork rather than direct inspection. The key difference is not speed alone. It is that every step produces verified information rather than an assumption. The database check either finds the rows or it does not. The Playwright screenshot either shows the bug or it does not. You are not reasoning from description, you are reasoning from evidence.

The CLAUDE.md Layer

MCP servers handle tool access. CLAUDE.md files handle context. You need both. Without CLAUDE.md, every session starts with explaining the plugin architecture. With CLAUDE.md, Claude reads it automatically at session start and knows the key files, the architectural decisions, and what constraints apply. I wrote about enforcing consistent WordPress Coding Standards across all my projects, the CLAUDE.md approach follows the same principle: establish rules once, apply them everywhere automatically.

Every plugin repository has a CLAUDE.md at the root. It covers architecture, key files, database structure, known gotchas, and explicit behavioral constraints, including what Claude should not do. The constraints section matters as much as the architecture section. Without it, Claude makes reasonable but wrong choices: suggesting jQuery in a vanilla JS codebase, adding docblocks to functions you did not ask it to touch, proposing solutions outside the scope of what you asked.

# BuddyPress Hashtags

## Architecture
- Save layer: parses hashtags on bp_activity_posted, stores as meta _bp_hashtag
- Display layer: replaces #hashtag with link at render time
- Search layer: REST endpoint /wp-json/bp-hashtags/v1/search

## Key Files
- includes/class-hashtag-parser.php, regex, sanitization
- includes/class-activity-hooks.php, all BP hook registrations
- public/js/autocomplete.js, vanilla JS, no jQuery dependency

## Constraints
- No jQuery suggestions, codebase is vanilla JS
- No changes outside what I explicitly ask
- No docblocks added to code I did not ask you to touch

What to Set Up First

If you are starting from scratch, the order matters. Do not try to set up all 19 servers at once, you will spend a day on configuration and not see enough benefit to sustain the habit. Start with the four that give the most immediate value for WordPress plugin development specifically.

Filesystem MCP, scoped to your WordPress development directory. This alone changes how you work with Claude on plugin code. Claude goes from reasoning about code you describe to reasoning about code it can actually read.
GitHub MCP, closes the loop from fix to PR. Use fine-grained tokens per repository, not a blanket token. The security model matters when you give an AI tool write access to your repositories.
A MySQL MCP for local WordPress, this is a half-day to build with the MCP SDK and mysql2. But the daily debugging time savings are substantial. Most database-layer questions that currently require phpMyAdmin round-trips will take seconds instead of minutes.
Playwright MCP, describe test scenarios in plain language, Claude runs them in a real browser. This eliminates a category of manual verification work entirely.

CLAUDE.md files for your most-worked-on plugins should happen in parallel with this setup. Write them once and every subsequent session benefits. The remaining servers in my stack evolved over six months of real usage, add them based on what actually slows you down, not based on what sounds useful in theory. If you want to see how far custom server development can go, the MCP server I built for WordPress to Astro migrations shows what is possible when you build for a very specific problem.

The MCP ecosystem for WordPress is still early. Most of what I use is either official Anthropic packages or custom servers built for my specific workflow. The developers who build these habits now will be significantly ahead when purpose-built WordPress MCP servers become more widely available, they will already know exactly what to configure and why.