MCP is an integration boundary, not a plugin format

A familiar problem in new clothes

Enterprises have spent two decades learning how to expose systems to consumers safely: API gateways, scoped credentials, audit logs, versioned contracts. The Model Context Protocol poses the same problem with a new consumer. Its architecture is explicit about the parties: hosts are the LLM applications that initiate connections, clients are the connectors inside the host, and servers are the services that provide context and capabilities — as tools, resources, and prompts, agreed through capability negotiation.

An MCP server is an API surface and deserves the discipline of one: declare capabilities explicitly, hold the narrowest credentials that do the job, log every call with enough context to reconstruct it, and version the contract so agent behavior does not change silently underneath its operators.

Where teams cut corners

The tempting shortcut is one MCP server with admin credentials to everything — it makes the demo work in an afternoon. It also concentrates exactly the risks the specification's own security guidance names: the confused deputy problem, token passthrough, session hijacking. The spec is equally blunt about trust — tool annotations must be treated as untrusted unless they come from trusted servers.

Per-system servers with scoped capabilities cost more setup and buy the property that matters: any single tool's blast radius is known in advance, and revoking one capability does not take the whole workflow down.

Governance is the feature

The organizations getting value from agents are not the ones with the cleverest prompts — they are the ones whose agents can be audited, scoped, and switched off per capability, with the spec's user-consent-and-control principle enforced at every boundary. Build the boundary first; the intelligence rents space inside it.