Connecting Claude to a WordPress Fleet in 2026: One of These Five Routes You May Already Be Paying For

Updated October 2026.

WordPress.com has run an MCP server at https://public-api.wordpress.com/wpcom/v2/mcp/v1 since 7 October 2025, and its own developer documentation, read on 2 October 2026, states that “one connection reaches every site on your account.” WP Rocket shipped an MCP in version 3.23 and its release post says the opposite: “each website must be connected individually,” verified on the same date.

The comparison people expect is a list of WordPress MCP servers. The more useful comparison is a single axis: does adding your twenty-first site mean touching your AI client’s config, or not? This guide puts five routes on that axis, including one most roundups miss because it is not a plugin.

The correction this guide carries, if you read an earlier version of it: the official Automattic path is not only the per-site plugin. A self-hosted site connected through Jetpack reaches the same fleet-wide WordPress.com server, with no separate MCP server to set up. That changes the answer for anyone already paying for Jetpack, and it is Path E below.

Quick Summary: Which Route Fits Your Fleet

The one-line version: three of these five routes are one connection for a whole fleet, one is one connection per site, and the cheapest of the five is the one you may already be paying for.

Key takeaways

• The per-site path, Automattic’s MCP Adapter for the Abilities API, is one server per site. Correct for one or two sites, painful past five.
• WordPress.com’s own MCP server is fleet-wide, and Jetpack-connected self-hosted sites use that same server. It needs a paid plan.
• wp-mcp-router (free, open source) puts one router in front of many sites and routes by a site argument.
• InstaWP Account MCP gives one account-level connection for content and site operations.
• xSpeed Hub gives one connection for performance work across a fleet, with cross-workspace switching.
• Whichever you pick, verify with a read call before granting write access. The verification section below is the part of this guide to read twice.

Why the default setup does not scale

An MCP server is a process that exposes tools to an AI client. The per-site route runs inside a single WordPress install, so it exposes that one site’s tools and nothing else.

The useful analogy is phone numbers. The default setup gives every site its own number: to speak to site twelve, you dial site twelve. A router or hub setup is a switchboard, you dial one number and say which site you want. The switchboard knows the extensions.

That distinction is the entire decision. Everything below is a variation on “do I dial direct, or through a switchboard?”

Which method fits you

Work out your branch before touching any config:

Are your sites on WordPress.com, or connected via Jetpack AI / Jetpack Complete?
├─ Yes → Path E (WordPress.com MCP). One connection, already paid for.
└─ No  → Do you manage more than ~3 WordPress sites?
    ├─ No  → Path A (MCP Adapter, per site). Simplest, nothing extra to run.
    └─ Yes → What is the AI actually for?
        ├─ Content, posts, users, settings
        │   ├─ Comfortable self-hosting a router → Path B (wp-mcp-router)
        │   └─ Prefer a managed account         → Path C (InstaWP Account MCP)
        └─ Site speed, caching, Core Web Vitals → Path D (xSpeed Hub)

Action: count your sites, then answer two questions in this order. First, “am I already paying for Jetpack AI, Jetpack Complete, or a WordPress.com plan?” If yes, you have a fleet-wide server already and Path E costs you nothing new. Second, “do I want the AI to write posts, or to make pages faster?” Those are different tool sets, and no single server currently does both well.

Still choosing a server rather than wiring one up? 10 Best WordPress MCP Servers in 2026 ranks the category on live install data.

---

Path A. Official plugin, one connection per site

Free · Best for 1–3 sites · ~5 min per site

The official self-hosted route is the MCP Adapter, released by the Core AI team on 17 July 2025 and introduced to developers in February 2026 as part of the AI Building Blocks for WordPress initiative. Its job is to convert abilities registered through the Abilities API, which landed in WordPress core in 6.9, into MCP tools and resources. Both pages were read on 2 October 2026.

Note that this route is a developer package, not a directory plugin. A wordpress.org/plugins/wordpress-mcp/ URL returns a search-results page rather than a plugin listing, and the Plugin API returns a 404 for that slug, both checked on 2 October 2026. Anyone citing an install count for it has the wrong artifact.

1. In WordPress, go to Plugins > Add New > Upload Plugin and install wordpress-mcp, then click Activate.
2. Go to Settings > MCP and tick Enable MCP functionality.
3. Go to Users > Profile, scroll to Application Passwords, type a name such as claude-mcp, and click Add New Application Password. Copy the 24-character password. It is shown once.
4. In Claude Code, run:

   claude mcp add --transport http mysite https://example.com/wp-json/wp/v2/wpmcp \
     --header "Authorization: Basic <base64 of user:app-password>"

5. Repeat steps 1–4 for every additional site, giving each a distinct name (client-alpha, client-beta).

Trade-off: nothing extra to run and nothing to trust. But the work is linear in site count, and the assistant sees one site per named server, you must say which one every time.

---

Path B: wp-mcp-router, one router in front of many

Free, open source · Best for 4+ sites, self-hosted · ~15 min setup, ~2 min per site

wp-mcp-router sits in front of your sites and routes calls by a site argument, so the AI client holds one connection. It discovers each site’s ability catalogue and caches it.

1. Install the router per its README and give it a config listing each site’s URL plus its application password.
2. Create an application password on each site as in Path A step 3, the router still authenticates per site.
3. Point your client at the router once:

   claude mcp add --transport http wp-router http://localhost:PORT

4. Address sites by name in conversation: “List draft posts on client-alpha.”

Trade-off: one connection and full control, but the router is infrastructure you run, patch, and keep available. Its credential file holds every site’s password, so it needs to be treated as a secret store. If you are weighing the self-hosted options on install data rather than on architecture, 10 Best WordPress MCP Servers in 2026 re-queries the whole directory.

Warning: do not put the router on a public address without authentication in front of it. It is a single point of access to every site in the config.

---

Path C. InstaWP Account MCP

Best for content work across a managed account · ~2 min per site

InstaWP distinguishes Site MCP (inside one site) from Account MCP (across the whole account). Account MCP is one connection covering the account, and with the opt-in “act inside sites” capability it can reach the MCP inside each site beneath it.

1. Connect each site to your InstaWP account.
2. In InstaWP, mint an Account MCP connection.
3. Enable act inside sites only if you want the AI reaching into individual installs.
4. Add the connection to your client once:

   claude mcp add --transport http instawp <account_mcp_url>

Trade-off: nothing to self-host, and adding a site does not touch the client. You are trusting a third party as broker, and the tool surface is content and site operations rather than performance.

---

Path D: xSpeed Hub, one connection for performance

Free tier · Best for caching and Core Web Vitals across a fleet · ~2 min per site

This is the path we build, so treat the framing accordingly: it covers performance only. It exposes no tools for writing posts or managing users. If your job is content, Paths B, C and E are the right ones and this will not help. Disclosure: xSpeed Cache, xSpeed Scan and xSpeed Hub are WPDeveloper products, and WPDeveloper is a Startise company.

What a fleet-wide performance connection is actually for is catching the site whose dashboard says everything is fine. We read nine sites through one connection and found every cache flag returning true while one site had a 24-hour hit ratio of zero. The agency use case covers the fleet shape in more detail.

For caching work specifically, WP Rocket also shipped an MCP in version 3.23, though its own release post states that “each website must be connected individually. Connecting one site doesn’t automatically connect your other websites”, which puts it in the Path A shape. Re-read on 2 October 2026. We compare the two tool by tool in xSpeed Cache MCP vs WP Rocket MCP.

Connect each site (no token to copy anywhere):

1. Open the xSpeed Cache dashboard on the site and click Connect Hub in the top bar, or open the xSpeed Hub tab in the MCP Server panel under AI & agents.
2. Click Connect via xspeedcache.com.
3. Sign in with Google or an emailed magic link, then click approve on the attachment screen.
4. You land back on the site with the connection confirmed. The Hub measures it immediately, so its first speed score is already there.

Connect your AI client once:

5. In the Hub, open Connect and mint a connection.
6. Choose its scope: full access is the default, or restrict to read-only, to specific sites, or with named tools denied.
7. Paste the config into Claude, ChatGPT, or any MCP-compatible client. The steps for each one, starting with Claude, are in AI agents.

Every site added later appears in the existing conversation. The client is never reconfigured.

Requirements: a free account at app.xspeedcache.com, xSpeed Cache 1.1.0+ active on each site, and administrator access to attach.

Exclusion: local and development sites are skipped, because PageSpeed cannot reach them.

---

Path E: the WordPress.com server, which already reaches the whole account

Paid plan required · Best for sites already on WordPress.com or Jetpack · no per-site setup at all

This is the route most roundups of this category leave out, because it is not a plugin you install. WordPress.com runs an MCP server and its developer documentation, read on 2 October 2026, describes the reach in one sentence:

“WordPress.com exposes an MCP server for AI agents, at https://public-api.wordpress.com/wpcom/v2/mcp/v1. One connection reaches every site on your account, and one catalog of tools serves all of them. Self-hosted WordPress sites connected through the Jetpack plugin use this same server. There is no separate Jetpack MCP server to set up.”

Read the third sentence again if you run self-hosted sites. A Jetpack-connected WordPress.org install is reached by the same fleet-wide endpoint as a site hosted on WordPress.com, with the same tool catalogue. For a fleet that already runs Jetpack, the switchboard is built and switched on.

1. Confirm your plan. Per the same documentation: MCP access is available on all WordPress.com paid plans, and on a free WordPress.com site it works only for the first 30 days after the site is created. Self-hosted sites connected through Jetpack need a Jetpack AI or Jetpack Complete plan.
2. Enable MCP in your WordPress.com account settings.
3. Add the one server URL to your client. The server uses OAuth 2.1, which WordPress.com shipped in January 2026, so there is no application password to mint, copy or rotate.

Trade-off, and it is a real one in both directions. You get a fleet-wide connection with no infrastructure and no credentials in a config file, from the company that builds WordPress. You pay for it on every site, through a plan rather than a licence, and the tool catalogue is content and site operations: posts, site details, settings, statistics. It is not a performance tool set.

The requirement is the whole catch. Paths B and D have free tiers. This one does not: a fleet of ten self-hosted sites needs ten Jetpack AI or Jetpack Complete plans, which for most agencies will cost more than any of the alternatives on this page. If you are already paying for Jetpack on those sites, the marginal cost is zero and nothing else here competes with that. If you are not, price it before you choose it.

How to verify it actually worked

Do this before granting write access. Ordered easiest to most rigorous.

1. List the sites (10 seconds)

Ask the assistant to list what it can reach. On xSpeed Hub the underlying call is list_sites, and each row must read:

status: "verified"      ← required
scopes: ["read", ...]

Success threshold: every site you attached appears, and none shows status: "unreachable". An unreachable site fails silently inside a fleet-wide call, the call reports success overall while quietly skipping that site.

2. Read something real (30 seconds)

Ask for a live metric: cache status, or hit ratio. A healthy, warmed page cache reports a hit ratio of 90–99%. Anything under ~50% usually means the cache is cold rather than broken; run the preloader and re-check.

Failure looks like: an authentication error, or an empty result where a site should be. First debugging step is re-minting the connection, expired or mis-scoped credentials are the common cause.

3. Confirm the fleet is really one connection (1 minute)

The real test of Paths B, C and D: attach one more site, then ask the assistant about it without touching your client config. If it answers, the switchboard works. If you had to edit config, you are effectively still on Path A.

For multi-workspace setups, list_workspaces should return each workspace with reachable: true. A workspace showing reachable: false means you belong to it but did not grant it at consent, no tool call can widen that; reconnect and tick it.

What this costs over a year, which is the comparison nobody runs

Setup minutes are the number every guide quotes, and they are paid once. The recurring cost is what decides a fleet, and it splits cleanly: Paths A, B and D charge nothing per site for MCP access, Path C and Path E charge per site through a plan.

Work it on ten self-hosted sites. Path A costs ten application passwords and ten entries in a client config, forever, plus the rotation work. Path B costs one server you run and patch, and one credential file holding ten passwords, which is a secret store whether you treat it as one or not. Path D costs nothing for the free tier and reaches all ten through one connection, for performance only. Path E costs ten Jetpack AI or Jetpack Complete plans, which is real money, and in exchange costs zero minutes and zero credentials because the sites are already connected and the server uses OAuth 2.1.

The honest ranking depends entirely on whether those Jetpack plans already exist. If they do, Path E is free at the margin and nothing here beats it for content work. If they do not, it is the most expensive option on the page and Paths B or C are the sensible content answer. That is why the first question in the decision tree is a billing question rather than a technical one.

Warnings and exclusions

• Take a backup before granting write scope. Write access is genuinely useful and genuinely consequential.
• Start read-only. Widen scope after you have watched the assistant work for a few days.
• Never commit application passwords to Git. Paths A and B both produce credentials that end up in config files.
• One MCP server per job. Running several with overlapping tools confuses the client and widens exposure.
• Firewalls block this. WP Rocket documents “Couldn’t reach [connector]” errors when a host blocks Anthropic IP ranges; the same class of rule affects every server here. Allowlist the client’s IPs.

Maintenance

• Rotate application passwords on a schedule for Paths A and B. They do not expire on their own.
• Re-check scopes quarterly, especially after someone leaves a team.
• Detach sites you no longer manage. With xSpeed Hub, removing the site from either side kills the Hub’s credential immediately; caching on the site is unaffected.
• Watch for unreachable. It is the failure mode most likely to go unnoticed, because fan-out calls report partial success as success.

Frequently Asked Questions About Reaching a Fleet

It says “Couldn’t reach [connector]”. What do I do?

Your host is almost certainly blocking the AI client’s IP ranges. Ask them to allowlist Anthropic’s, or test from a different network to confirm before changing anything.

A site shows status: "unreachable", is it broken?

Not necessarily. It usually means the site is down, behind HTTP auth, or its credential was revoked. Re-run the connection flow from the plugin side. Until it reads verified, fleet-wide calls will skip it.

A workspace shows reachable: false. How do I fix it?

You belong to it but this connection was not granted it. No tool call can widen a connection’s reach, reconnect from xspeedcache.com and tick that workspace at the consent screen.

The assistant says it has no tools available.

The connection was added but not authorized. Check the credential, and confirm the client actually restarted after the config change. Claude Desktop needs a full quit, not just a window close.

Can I use ChatGPT instead of Claude?

Yes. MCP is an open standard, so any MCP-capable client works. Vendors document Claude most often because it shipped support first. For Path D, the ChatGPT setup guide has the steps.

Do I have to pay for any of this?

Not for all of it. The MCP Adapter, wp-mcp-router, and xSpeed Cache’s free tier all include MCP at no cost. Path E is the exception: the WordPress.com server needs a paid WordPress.com plan, or Jetpack AI or Jetpack Complete on a self-hosted site.

I am on a free WordPress.com site and MCP stopped working. What broke?

Probably nothing broke. Per WordPress.com’s own developer documentation, MCP access on a free site works for the first 30 days after the site is created. After that it needs a paid plan. Check the plan before debugging the client.

I already pay for Jetpack. Do I still need to install an MCP plugin on each site?

Not for content work. WordPress.com’s documentation states that self-hosted sites connected through the Jetpack plugin use the same server as WordPress.com-hosted sites, with no separate Jetpack MCP server to set up, on a Jetpack AI or Jetpack Complete plan. You would still need a separate server for caching and Core Web Vitals work, because the WordPress.com tool catalogue does not cover them.

Which of these five is actually one connection for a fleet?

Three of them: B, C and E for content, and D for performance. Path A is one connection per site by design. The test in the verification section settles it in about a minute: attach one more site and ask about it without editing your client config.

Can the AI break my site?

It can change settings if you grant write scope. Back up first, start read-only, and prefer servers that verify or roll back their own changes.

Can one connection do both content and performance?

Not today. Content servers expose posts, users and settings; performance servers expose caching and metrics. Running one of each is the current answer.

Does connecting to a hub mean my pages are served by someone else?

Not with xSpeed Hub. It brokers control only; your pages are still cached and served by your own site. NitroPack-style cloud services are different and do sit in the delivery path.

Which to choose

Check Path E first, because it may already be paid for. If your sites are on WordPress.com, or on Jetpack AI or Jetpack Complete, you have a fleet-wide content server and there is nothing to install. If they are not, start with Path A even if you plan to scale: connecting one site teaches you what the tools actually do, and it is five minutes you will not regret. Move to a switchboard when the config file starts annoying you, which in practice is around the fourth site.

What to do this week: count your sites, then check one thing before touching any config. Open your billing and look for Jetpack AI, Jetpack Complete or a WordPress.com paid plan. If it is there, Path E is already yours for content work and you only need a second server if your job is performance. If it is not, pick between B, C and D on the table above rather than wiring twenty copies of Path A. And whichever route you take, run the free xSpeed Scan on two or three of the sites first: it needs no account and no connection, and knowing which sites are actually slow tells you whether you need a performance tool set at all.

Related reading

• 10 Best WordPress MCP Servers in 2026. Pick a server before you wire one up
• xSpeed Cache MCP vs WP Rocket MCP: the two performance servers, compared tool by tool
• 9 Best WP Rocket Alternatives in 2026, caching plugins ranked on Core Web Vitals field data

Working on performance specifically? The xSpeed Cache MCP tool reference is the guide to the commonly used tools, and it is worth knowing that there is no fixed number of them: the page states that “the connected server’s current tools/list response is authoritative” and that the catalogue varies with plugin version, registered modules, licence and connection scope. An earlier version of this article quoted a figure of 26, which was wrong in kind as well as in value. Ask your own client to list the tools, and read what an agent can actually call on your site for the Site and Hub catalogues side by side and which twelve calls write. Connecting to xSpeed Hub covers the attachment flow in more detail, and scoped AI connections explains how to restrict what an assistant may touch.