An engineer asks an assistant: “Which deployment preceded the checkout incident, and what should we investigate?” The answer needs an incident system and a deployment system. Tomorrow the same capabilities need to work in a different assistant. Next quarter, your company wants to expose its own incident product to customers using several different assistants.
MCP addresses a real part of this problem: a shared way for an AI application to discover and use external capabilities. It does not decide whether a deployment caused an outage, whether a particular person may read an incident, or whether a retried write should execute again. Understanding that boundary is the foundation of this series.
Two phases, in this order
Phase 1 establishes the protocol. We compare alternatives before writing a server. Then we follow a request through the host, client, server, and application, including discovery, transport, errors, and the limits of the contract.
Phase 2 applies that understanding. We operate several connections, study established providers, design a multi-tenant service, run a small real integration, and define the evidence needed before serving customers.
| Part | Question it answers |
|---|---|
| 1. Why MCP? | What does it standardize, and when do APIs or CLIs remain a better choice? |
| 2. How the protocol works | What happens on the wire, what changed in 2026, and what is optional? |
| 3. Consuming multiple servers | How do identities, tool selection, data flow, and partial failure compose? |
| 4. Lessons from established operators | What can we actually learn from GitHub, Stripe, Cloudflare, Anthropic, and Block? |
| 5. Serving hundreds of customers | Where do authorization, replay safety, capacity, and ownership belong? |
| 6. Build and run the example | How do two real MCP servers and one client make these boundaries visible? |
| 7. Graduate to production | What must be demonstrated before onboarding real customers? |
The dated baseline matters
Research date: 15 October 2026. The protocol baseline is 2026-07-28. The local example pins the TypeScript SDK packages to 2.3.1, uses JavaScript ESM, and explicitly selects the modern protocol era. The specification release and SDK migration guide are separate references: an SDK package version is not a negotiated wire version.
Older material remains useful when labeled. A tutorial built around initialize, protocol sessions, or resumable SSE may describe an earlier revision correctly while being the wrong implementation guide for a new 2026 service. This series explains the migration boundary rather than blending those behaviors.
What depth means here
The starting assumption is L6-level engineering experience: you can reason about HTTP, schemas, identity, databases, and distributed failures. You do not need prior MCP knowledge. L7/L8 are used as a progression in decision scope, not an employer’s promotion rubric.
| Depth | Demonstrable capability |
|---|---|
| L6 starting point | Explain a complete call, debug an error, choose an interface, implement a bounded tool |
| L7 system judgment | Establish contracts across teams, isolate failures and tenants, measure task quality, design migrations |
| L8 organizational judgment | Decide which capabilities should be exposed, assign durable ownership, evaluate platform economics and systemic risk |
Knowing method names is insufficient. So is listing security risks without saying where enforcement occurs. The intended outcome is the ability to defend a design with explicit assumptions, counterexamples, and tests.
Three kinds of evidence
Protocol facts cite versioned specifications. Operator observations cite a provider’s own documentation or engineering account, with limits on what that proves. Design recommendations are our synthesis and are labeled as such; workload numbers are illustrative unless explicitly measured.
The public companion examples use synthetic data, fixture identities and local subprocesses. The baseline demonstrates discovery, calls, tenant checks and process-local replay. An optional SQLite extension adds durable replay across concurrent workers and process replacement on one host, including crash tests. Neither demonstrates OAuth, multi-host distributed transactions, an LLM’s tool-selection quality, or a fleet serving 300 customers. Keeping these claims separate is part of engineering rigor.
A question to carry through the series
Suppose every API already has OpenAPI documentation, a maintained SDK, and an excellent CLI. What does MCP still buy you?
Write an answer before reading the next chapter. A good answer must identify a recurring integration cost that a shared protocol removes, and a cost it cannot remove. “It lets AI call tools” is incomplete: that was already possible.