What is an MCP Fleet?

MCP adoption rarely happens through procurement. A developer adds a server to their MCP configuration to solve today's problem; a teammate copies the config; an agent framework ships with defaults. Multiply by every engineer and every host — Claude Code, Cursor, IDE plugins, CI agents — and the organisation is soon running dozens of servers nobody chose deliberately. Fleets sprawl because adding a server is a one-line config edit with no central registration step.

Sprawl has concrete costs. Each server in the fleet is executable code with credentials: API keys in env blocks, OAuth grants to SaaS systems, database connection strings. Unowned entries become shadow MCP — servers security teams don't know exist. Overlapping servers create tool sprawl, where hundreds of tool definitions burn context tokens and confuse models. And when a popular server ships a compromised release, the first incident-response question — who is running it? — is unanswerable without an inventory.

Treating MCP usage as a fleet means applying the disciplines used for device or service fleets:

• Inventory — a live register of which servers, versions and tools are in use, and by whom.
• Identity and credentials — per-person scoped access instead of shared keys scattered across laptops.
• Policy — uniform rules over what tools may be called, enforced centrally rather than per machine.
• Audit — one record of every tool call across the estate.

PolicyLayer is a control plane for MCP fleets: teams register their upstream servers once, issue per-person scoped tokens, and route all clients through the gateway. That turns an unobservable scatter of local configs into a managed fleet with an inventory, deterministic per-call policy, and a complete audit trail.