I run more than one WordPress site: Popup Maker, Content Control, two storefronts, and this blog. Working with all of them through Claude Code and MCPs, you quickly drown in tools. I’ve been connecting each one with the Abilities API and the MCP Adapter plugin. Plugins register “abilities”, which the adapter exposes as MCP tools, letting agents actually do things on the site instead of just reading it.
The catch is that the official setup is one connection per site.
The problem
Automattic’s @automattic/mcp-wordpress-remote is one process per one site. Managing five sites meant five MCP servers in my config, five application passwords, and an agent that could only see one site at a time.
Worse, agents struggle to differentiate between sites. Each one exposes a different set of abilities. A Popup Maker site has popup tools and FluentCRM; a basic storefront doesn’t. When an agent gets asked to “create a popup”, it can’t figure out which connection has that capability. So it guesses, calls the wrong site, and gets back an unclear error.
On the command line, we already solved this. Tools like ssh wppopupmaker or wp @wppopupmaker core version give you one alias per site and one tool that knows them all. I set out to solve this the same way: shared tool calls and a site name selector.
What’s already out there
Multiple WordPress MCP servers exist, and some handle multiple sites. But they all talk to WordPress core’s /wp/v2 REST API using a fixed, hand-written collection of tools. That means they can’t access a plugin’s own abilities unless you explicitly code support for each one. The tools built on the Abilities API — which do see plugin abilities — are all single-site implementations. None of the existing MCPs that federate to multiple sites worked with the MCP Abilities APIs.
So I built one.
wp-mcp-router
wp-mcp-router is a simple MCP server positioned in front of all your sites. You connect to it once and can address any site by name. It uses the same endpoint and session handshake as Automattic’s proxy, but routes to multiple sites via a site argument instead of running one process per site.
This gives you a few things.
- It reads each site’s real ability catalog and caches it, so the agent knows where a capability lives before calling anything.
- You can search abilities across every site at once — “which of my sites can create a popup?” now has an answer.
- Calls are guarded. If you call an ability on a site that doesn’t have it, you get back “not on B; available on A and C” instead of an opaque failure.
Once connected, your agents get the full suite of abilities & tools each site exposes. There’s nothing to maintain per plugin. When a plugin registers a new ability, it becomes available on every site through the single connection.
Getting started
Each site needs the mcp-adapter plugin active. That’s it. Setup is two commands.
# 1. Connect a WordPress site
npx wp-mcp-router add-site example.com
# 2. Wire it into your AI client
npx wp-mcp-router installThe first opens your browser to WordPress core’s Application Passwords screen, which works like an OAuth prompt. You approve the generated password and paste it in once. The second command adds the server to your AI client’s config, detecting Claude Desktop, Claude Code, Cursor, and Codex. Restart the client, and you’re connected. Adding more sites is just add-site again — less than a minute per site.
A note on security
The credential is a scoped, revocable application password — never your real login — and you can remove it from the profile anytime. The router runs under a deliberately limited role so if a credential gets compromised, an agent could modify content but not execute code or escalate privileges. Every call the router makes is recorded in a local audit log by default.
The project is open source and on npm: github.com/danieliser/wp-mcp-router. Issues and pull requests are welcome.