AI Reality Checks #19 · Part of Binary and Beyond. LinkedIn newsletter edition follows.
The slide says MCP connected.
Three servers are listed. The agent can read CRM records, search docs, and post a draft reply. Someone in the room says the integration layer is done.
They are looking at the plug.
They are not looking at the wiring behind the wall.
Model Context Protocol is a real step forward. It gives agents a common way to discover tools, pass arguments, and receive structured results. Less bespoke glue per vendor. Faster experiments. A shared vocabulary for "this model can call that capability."
That is worth celebrating.
It is also where many teams stop thinking — exactly where the expensive work begins.
MCP is not an architecture.
It is a transport and discovery layer for tool use. Auth boundaries, data contracts, rate limits, audit trails, ownership, partial failure, and idempotency still belong to the people who own production. The protocol did not delete those problems. It made them easier to ignore for a few weeks while the demo looked complete.
The demo that ends at "connected"
Picture a product team wiring an internal copilot to three MCP servers: CRM lookup, knowledge base search, and a ticketing API.
The first session is magic.
An exec asks for an account summary. The model pulls the record, cites two support threads, and drafts a follow-up. Leadership green-lights rollout. Engineering logs the milestone: MCP integration complete.
Week three, a different story.
A support lead notices duplicate tickets because the model retried a slow write. Compliance asks who can see PII through the doc server and gets a shrug between "the model" and "the vendor." A schema change in the CRM breaks field mapping; nobody owns the server manifest. Incidents arrive as "the AI hallucinated" when the tool returned stale inventory and the model narrated confidence.
None of that is MCP failing.
That is integration maturity arriving on the same schedule it always has — after the protocol slide looks green.
What MCP actually standardizes
Think of MCP as agreeing on how a model asks for a capability:
- What tools exist
- What inputs they accept
- What shape results come back in
- How sessions and resources are named
That removes a class of one-off adapter work. Good.
It does not standardize:
Authorization. Which identity is the model acting as? Which rows may it read? Which mutations require a human? MCP servers still need the same OAuth, scoped tokens, and row-level rules every API programme needs.
Data contracts. Field meanings, enums, null semantics, and "this number includes holds" still have to be documented and enforced. Models amplify contract drift; they do not forgive it (AI Reality Checks #18, Production Notes #10).
Side effects and idempotency. A tool that creates tickets, sends email, or updates billing is a write path. Retries, timeouts, and duplicate calls need keys and compensation — the same bills as any distributed integration (Production Notes #05, Production Notes #06).
Observability. You still need traces that tie a model turn to each tool call, latency, error rate, and payload shape. "Connected" is not a metric. Safe actions per hour with audit is a metric.
Ownership. When the CRM MCP server breaks after a field rename, who is paged — the AI team, the CRM team, or the vendor who shipped a sample server? Protocols do not assign on-call.
MCP moved complexity out of adapter boilerplate and deposited it where it always lived: production boundaries.
That is the same move AI Reality Checks #16 described. Delete visible glue; inherit verification, contracts, and failure design.
USB-C is the honest analogy
USB-C did not make peripherals trustworthy.
It made them interchangeable at the connector.
You still choose which drive holds customer data, which cable supports the wattage you need, and which hub overheats under load. The standard reduced friction at the edge. It did not remove electrical engineering.
MCP is the connector for agent tools.
Teams still need the electrical engineering: threat models, schema owners, SLOs, rollback, and runbooks when the model plus tools disagree with reality.
Immature programmes measure servers connected.
Mature programmes measure mutations bounded, auditable, and recoverable.
The stack below the protocol
A useful way to read an MCP rollout:
Model + prompt
↓
MCP session (discovery, calls, resources)
↓
Server implementation (your code or a vendor's)
↓
APIs, databases, queues, SaaS — the same systems you already operate
Most incidents will originate at the bottom two layers.
The model will take the blame because it spoke last.
Production reviews should start at the bottom and work up: what can each tool actually do to production state, and under whose authority?
When we wire AI app delivery for clients, MCP often appears in week two of the conversation. Week six is still about pending states, authority maps, and eval suites — the same shape as pre-MCP integrations.
Partial success gets fluent
Tool paths commit in pieces.
One MCP call succeeds. Another times out. A third returns cached data that lagged reality by an hour. The model produces a single paragraph that sounds settled.
That is eventual consistency with a confident voice (Production Notes #09). MCP did not invent the pattern. It makes multi-tool flows cheap enough that teams run them before they name which system's truth wins.
Design responses that do not depend on the model self-correcting:
- Named pending states when downstream systems disagree
- Read-only tools separated from mutating tools in review policy
- Human gates on irreversible MCP mutations
- Eval cases that include partial tool failure, not only happy paths
If your test suite only covers "all tools returned 200," you tested the connector — not the product.
Governance is not a late add-on
Once multiple MCP servers exist, you have a marketplace inside your org.
Who may publish a server? Who reviews new tools for a production agent? Can a marketing experiment register a write-capable server next to finance read tools in the same session?
Without governance, "connect everything" becomes "expose everything to stochastic routing."
Minimal governance that survives audit:
| Question | Why it matters |
|---|---|
| Who registers servers for production agents? | Prevents shadow write paths |
| Which environments may mutate data? | Dev servers leak into prod sessions |
| What PII classes may leave which boundary? | MCP does not redact; servers must |
| How are server versions pinned and rolled back? | Prompt changes are not the only drift |
| What is logged per tool call for compliance? | "The model did it" is not a record |
This is boring work.
It is also the difference between a demo and something legal will sign.
A checklist after "MCP connected"
Use this when a stakeholder says the agent integration is finished:
- List every mutating tool. Reads are cheap; writes need owners and idempotency.
- Map authority. If CRM and warehouse disagree, which MCP result is canonical?
- Document contracts per server. Field meanings, enums, freshness, error shapes.
- Define session identity. User-delegated, service account, or impersonation — and what each may touch.
- Separate prod and experiment servers. Same protocol, different registration namespace.
- Add tracing. Model turn → tool call → downstream API → business outcome.
- Write evals for tool failure. Timeout mid-flow, stale read, partial write, schema mismatch.
- Name on-call. Server maintainer, not "the AI vendor."
If items 2–8 are TBD, MCP is connected.
Integration is not.
What good looks like six months in
Calm teams treat MCP like any other integration surface:
- Servers are versioned products with owners, not repo demos
- Mutations go through the same change control as REST endpoints
- Data contracts are tested when upstream schemas move
- Review policy matches risk — drafts automatic, refunds not
- Dashboards show tool reliability, not only model fluency
They do not argue about whether MCP was the right protocol.
They argue about which production boundaries each server is allowed to cross — and whether the agent programme budgeted for that work after the connector slide looked done.
Related reading
- AI Doesn't Eliminate Complexity. It Moves It.: tool paths deposit verification and ownership work
- Why AI Needs Better Data Than Humans Do: models cannot absorb the spreadsheet workarounds
- Every Integration Is a Distributed System: MCP servers are integrations with a new plug
- Data Contracts Matter More Than APIs: schemas are load-bearing for tool results
The honest close
MCP is a good beginning.
It lowers the cost of trying agent tool use and gives the industry a shared connector.
It does not replace integration engineering, data discipline, or operational ownership. Those were the hard parts before MCP. They still are.
The teams that win will not be the first to show a connected server list.
They will be the first to show bounded, auditable tool paths — with contracts, auth, and failure design that survive the Monday after the demo.
MCP is the USB-C moment. The product is still everything behind the port.