Chapter 1: MCP in Context
MCP exists because “just let the model call the tool” turned out to be a terrible long-term integration strategy.
Before MCP, every serious AI product built its own connectors for filesystems, ticketing tools, databases, browsers and internal services. Every new client repeated the work. Every new tool vendor had to decide which clients to support first. Every enterprise team ended up with one-off glue code that only made sense inside a single product.
The problem was not only duplication. It was fragmentation of behavior. One client might represent tools one way, another might expose resources differently, and a third might have no concept of reusable prompts at all. The result: brittle integrations, unclear security assumptions, and effort spent translating between near-identical ideas.
Take one issue tracker that three hosts need to reach:
| Before MCP | With MCP | |
|---|---|---|
| What you build | Three connectors, one per host’s plugin format | One MCP server |
| Auth | Three token flows wired into three products | One OAuth-protected resource |
| A new field on an issue | Three code changes, three releases | One schema change |
| A fourth host | A fourth connector | A configuration entry, plus testing |
Rule for this chapter: a shared protocol removes the integration work, not the per-client testing.
The N x M Problem
With N hosts and M backends and no shared protocol, every connection is custom work: each new backend repeats discovery, auth, invocation, error translation and UI wiring for every host.
MCP turns N x M integrations into N + M: each backend ships one server, each host ships one client. What it doesn’t remove is the behavior matrix. Hosts still differ in which primitives, schema features and approval flows they honor, so you still test and patch per client. Part V is about that residue.
The server I run for Atelier customers lets them edit their own live websites through ChatGPT, Codex or Claude. It is one server with per-client work in it anyway. ChatGPT needs a CORS preflight answered, its own widget metadata, and client registration proxied so it gets the openid, profile and email scopes it may request at sign-in. Codex needs the required scope listed in the server’s metadata. None of that is integration code. All of it is residue.
Why the “USB-C for AI” Metaphor Mostly Helps
People often call MCP “USB-C for AI.” The metaphor is useful as a first approximation, but it hides three important realities:
- MCP is not a physical plug. Capability discovery, auth, approval flows, and runtime behavior still vary by client.
- Plug compatibility does not imply behavior compatibility. Two clients may both support tools but differ sharply in resources, prompts, approvals, or UI.
- The hard part is semantic design as much as transport. A bad tool surface remains bad even when it speaks a standard protocol.
If the metaphor pushes you toward simplicity, keep it. If it makes you underestimate design work, drop it.
What Actually Changed: AI Access Became Governable
A protocol becomes strategically useful once governance teams can reason about it too. MCP gives clients and servers one control plane for model-facing capabilities, and that makes three things easier:
- Server builders can target a protocol instead of a single product.
- Client builders can integrate new capability sources without inventing a bespoke connector format every time.
- Organizations can talk about policy, approval, auditing, and operability against a common interface.
Security review, tenancy and approval UX get simpler when every tool arrives in the same shape, with the same annotations and auth challenge.
Where MCP Fits in the Stack
MCP is not the model, your business logic, your identity provider, or your orchestration engine. It sits between the model-facing client and the systems you want exposed. That position lets it make tool use portable and centralize scattered access patterns. It also makes it the place where bad abstractions harden:
- exposing an internal API one-to-one instead of designing for intent,
- smuggling privileged operations behind vague tool descriptions,
- or building an “AI layer” that really just hides a weak product decision.
MCP earns its cost when a capability must outlive one client; it rarely does for a single-user CLI wrapper. Chapter 3 turns that into a decision rule.
What Comes Next
A shared protocol removes the integration work, not the per-client testing, and it doesn’t say who is responsible for what. Judgment starts with knowing where the boundary sits: who asks the user, who validates the call, who owns the side effect. That’s Chapter 2.