Day 2 · Lesson 4 — Agent Tools & MCP

MCP For and Against: The Honest Ledger

Genuinely useful. Genuinely incomplete. The gap is where governance lives.

Lesson 3 gave you the architecture. This one weighs it honestly, because the most important fact about MCP is the shape of the gap between what it delivers and what an enterprise needs, not any single feature or flaw. That gap has a name you already know.

Recall first (spacing)

From Lesson 3: in MCP, who is defined to enforce security policy?

The Server alone
The Host application
The model itself

The Host. That's the natural choke point. Hold it: this lesson is about the fact that the choke point exists but the base protocol doesn't fill it.

For — what MCP genuinely buys you

A reusable ecosystem. Build a tool once, share it; the MCP Registry gives a central source of truth and network effects.¹
Dynamic tool discovery. Agents discover tools at runtime instead of hard-coding them, which makes them more adaptable and more autonomous.
Architectural flexibility. The agent is decoupled from each tool's implementation, so you can swap LLM providers or backend services without re-architecting the integration layer (the "agentic AI mesh").
Governance hooks. A server can be a single point of policy enforcement; Google's platform adds an Agent Registry + per-agent Agent Identity, and the spec recommends user consent before tool calls (human-in-the-loop).

Against — what it still lacks

Two families of problem. First, performance & scale:¹

Context-window bloat — for the model to know which tools exist, the definitions and schemas for every tool from every connected server must sit in the context window. This is the seed from Lessons 1 and 3, now sprouted: real cost, real latency, lost context.
Degraded reasoning — an overloaded context makes the model pick the wrong tool or lose the user's intent.
Stateful-protocol drag — persistent remote connections are harder to scale and load-balance than stateless REST.

Second, and this is the real story, enterprise-readiness gaps in the base protocol:¹

Gap	What's missing	Maps to
Auth & authz	No enterprise-ready standard; OAuth conflicts with practice	V Validation / scope
Identity ambiguity	Can't tell if an action came from user, agent, or system	I Identity
No native observability	No standard logging, tracing, or metrics	E Evidence · T Transparency

The thesis — and it's the Day-2 punchline

MCP's biggest risks (supply-chain exposure, inconsistent security, data leakage, no observability) are all consequences of its decentralised, open-by-design origins. So the major enterprise players are not adopting the "pure" protocol. They wrap it in layers of centralised governance: gateways and managed platforms that impose the security, identity, and control MCP omits.¹

Read that twice: the enterprise future of MCP is MCP + a governance layer. That's the same sentence as the VERDICT framework, arrived at from the tooling side, not a side-note to it.

One nuance worth holding: the likely fix for context bloat is RAG-for-tools: retrieve the few relevant tools per task instead of loading all of them. But that opens a new attack surface: poison the retrieval index and you can trick the agent into calling a malicious tool. (Straight into Lesson 5.)

The governance layer, on the ledger

Governance overlay · Day 2 Lesson 4

The "against" column is a VERDICT shopping list

Look at the gaps table again: it is VERDICT, itemised. No enterprise auth/scope = the V Validation you must add. Identity ambiguity = the I Identity registry (per-agent cryptographic IDs). No native observability = the E Evidence + T Transparency layer (OTel traces, audit logs). The paper reaches VERDICT's conclusion without naming it: an open protocol, to be safe at scale, must be wrapped in centralised runtime governance.

Ladder read: "decentralised, everyone connects anything" is L1 Unseen by construction. The centralised gateway/managed-platform pattern the paper prescribes is exactly the EXPOSE→BIND→ENFORCE climb to L3 Controlled. MCP hands you the plug; the governance layer is the fuse box.

Through your three lenses

Individual (IC)

Connect only the servers you need. Every extra one taxes the context window and dilutes reasoning. Treat "it works on my laptop with three servers" as a prototype, not the production shape.

Team

Don't rely on the base protocol for auth, identity, or logging. Decide, as a team, which managed layer or gateway fills those gaps before wiring agents to real systems.

Organisation

Adopt MCP as MCP-plus-governance: a central gateway enforcing identity, allowlists, and observability. The "pure protocol" is a decentralisation risk at enterprise scale; the wrapper is the product.

Check the reflex

Recall, don't re-read.

Connecting many MCP servers most directly causes —

Faster tool calls
Cheaper inference
Context-window bloat

Every tool definition from every server loads into the context window: cost, latency, and diluted reasoning. It's Day 1 L4's static-context problem, arriving via tools.

A core enterprise-readiness gap in the base MCP protocol is —

No native identity or observability
Too many built-in guardrails
Excessive access control

The base protocol ships thin: no enterprise auth, ambiguous identity, no standard logging/tracing. Those gaps map straight onto VERDICT's I, V, and E pillars.

How do enterprises actually adopt MCP?

Using the pure open protocol
Avoiding MCP entirely
Wrapping it in centralised governance

Wrapped, rather than pure or banned. Gateways and managed platforms impose the security, identity, and control the open protocol omits. That wrapper is the governance layer.

Carry this into the week

Count the MCP servers one of your agents connects to, and estimate the tokens their tool definitions consume on every call. Then ask the harder question: for each server, who checks identity, and who logs the call? The blank answers are your governance backlog.

Go deeper (primary source)

The MCP architecture spec covers the primitives; for the enterprise-wrapper pattern, gateway products like Apigee and managed agent platforms are the working examples the paper cites.

Notes

Styer, Patlolla, Mohaan, Díaz & Nawalgaria, Agent Tools & Interoperability with MCP (Day 2), "Model Context Protocol: For and Against" pp.36–40 (advantages; performance & scale; enterprise-readiness gaps; the centralised-governance conclusion).

Up next → Day 2 · Lesson 5: The MCP Threat Landscape + Confused Deputy. The specific attacks the open protocol enables (tool shadowing, dynamic capability injection, the confused-deputy privilege escalation) and the defences that make up the governance wrapper.