Managing Many Client MCP Servers at Scale in WordPress

Lesson 6 solved how to stop rebuilding abilities for every new client. This lesson solves a related but separate problem: once you’re actually running that shared library across dozens of client sites, each with its own MCP server, how do you know what’s happening across all of them without logging into each one individually to check. Course 8’s multi-server architecture and Course 14’s multi-agent, multi-tenant patterns already answered the technical half of this question. Here it’s applied to the specific operational reality of an agency: many separate WordPress installs, each running the shared library from Lesson 6, that need to be operated as a fleet rather than as isolated one-offs.

What you'll learn in this lesson

Per-client server versus shared multi-tenant server

The real architectural choice, and which one fits an agency's actual constraints.

Naming and routing conventions across many client installs

Avoiding collisions once dozens of sites run the same shared library.

Operating a fleet, not one site

Listing, checking, and reasoning about many servers at once with WP-CLI.

What actually needs central visibility

Health, errors, and usage volume, distinguished from what stays genuinely per-client.

Prerequisites

Course 8’s multi-server architecture lesson (create_server(), per-server transport permission callbacks) and Course 14’s multi-agent orchestration patterns. This lesson applies both across separate client installs, not one site’s several servers.

Step 1: Per-client server versus shared multi-tenant server

Two real architectures for serving many clients’ AI features
Architecture	How it works	Best fit
Per-client server (one MCP server per client’s own WordPress install)	Each client site runs its own independent MCP Adapter instance, using the shared library from Lesson 6 but with entirely separate data and credentials	The common case for WordPress specifically, since most clients each run their own separate WordPress install already, this isn’t a choice you’re making so much as the shape WordPress itself imposes
Shared multi-tenant server (one central server routing to many clients’ data)	A single MCP server, following Course 8’s create_server() pattern, exposes abilities that internally route to the correct client’s database or API based on which client is calling	A genuinely centralized product you operate on clients’ behalf, closer to Course 14’s multi-tenant patterns, and a meaningfully bigger engineering and security undertaking than per-client servers

For most agencies delivering AI/MCP work to WordPress clients, each client already runs their own separate WordPress install with its own database, so a per-client server is the natural default, not a deliberate architectural choice. The shared multi-tenant model becomes relevant only if you’re operating something closer to a managed platform on clients’ behalf, where isolating tenants by permission and routing (Course 14’s actual subject) rather than by separate WordPress installs is the whole point.

Don't reach for shared multi-tenant infrastructure by default

A shared server routing to many clients’ data concentrates risk: a bug in the routing logic can leak one client’s data into another client’s response, a failure mode that simply can’t happen when clients are on fully separate installs. Reach for it only when a genuine platform business model justifies the added engineering and security surface, not as a default way to save infrastructure cost.

Step 2: Naming and routing conventions across many client installs

Even with per-client servers running on entirely separate installs, consistent naming still matters the moment you’re operating more than a handful of clients, since it’s what makes fleet-wide tooling (Step 3) possible at all.

Conventions worth standardizing across every client install

A consistent server_id pattern

Something like client-acme-primary, so scripts querying multiple installs can identify which server belongs to which client at a glance.

A consistent ability namespace prefix

client-acme/list-service-listings rather than a generic namespace that collides in meaning across clients even though the installs are separate.

A shared library version reported somewhere queryable

So you can answer "which clients are still on an old, unpatched version of our ability library" without checking each site by hand.

Step 3: Operating a fleet with WP-CLI

Course 8 covered wp mcp-adapter list for seeing every server on one site. At agency scale, the same command, run against many client sites, is how you check fleet health without logging into each dashboard individually:

# File: terminal, run against each client site's WP-CLI alias
wp @client-acme mcp-adapter list --format=json
wp @client-widgetco mcp-adapter list --format=json

# File: terminal, a simple fleet-wide health sweep using WP-CLI aliases
wp @all mcp-adapter list --format=json > fleet-servers.json

Combined with the shared library version constant from Lesson 6, a script parsing that output can answer, in one pass, “which client sites are running an outdated library version” or “which client sites have no MCP server registered at all,” turning what would otherwise be dozens of manual checks into one repeatable command.

Step 4: What actually needs central visibility

Not everything needs to be centralized. A client’s actual content and business data should stay exactly where WordPress already keeps it, on that client’s own install, consistent with the per-client architecture from Step 1. What benefits from central visibility is operational health: is the server up, is it erroring, is usage trending in a way that matters for the pricing model chosen in Lesson 2.

What to centralize versus what to leave per-client

Centralize: server health and error rates

Aggregated from Course 4's error handler and each site's audit log, so a problem on one client site surfaces without a manual check.

Centralize: library version per client

To know who needs an update rolled out.

Centralize: usage volume, if pricing depends on it

Relevant for usage/credits pricing from Lesson 2, tracked in aggregate for billing and capacity planning.

Leave per-client: the actual content and customer data

Stays on that client's own install, consistent with per-client architecture and the data-handling agreement from Lesson 4.

Recap

Most agencies serve clients who already run separate WordPress installs, which makes a per-client MCP server the natural default, not a deliberate architectural choice, and a meaningfully lower-risk one than a shared multi-tenant server that routes many clients’ data through one system. Consistent naming and namespace conventions, combined with WP-CLI aliases and the shared library’s version reporting from Lesson 6, turn fleet-wide operations into a repeatable script instead of dozens of manual dashboard checks. Centralize operational visibility (health, errors, usage volume), leave actual client data exactly where it already lives, on each client’s own install.

Resources & further reading

Multi-Server Architectures at Scale, Course 8
Multi-Agent Orchestration in WordPress, Course 14
Scaling Delivery Without Scaling Headcount, this course, Lesson 6, the shared library this lesson’s fleet operations depend on