3.4 Connection Protocols: MCP vs. Direct API/CLI vs. Agent-to-Agent

You've right-sized an agent's tools (3.1), scoped access to real identities (3.2), and designed how it retrieves data (3.3). Now a very practical question remains: HOW does Claude actually reach a given capability, mechanically? You could write a direct API call. You could shell out to a command-line tool. You could stand up a standards-based server. You could hand the whole request off to another autonomous agent. All four are legitimate — the exam isn't testing whether you know these options exist, it's testing whether you can pick the RIGHT one for a given situation, because picking the wrong one has real costs either way.

Here's the question that actually decides it, and it has nothing to do with which protocol feels most modern: who else is going to reuse this capability, and who is responsible for maintaining it? A capability built for exactly one app, that no one else will ever call, doesn't need the ceremony of a shared standard. A capability meant to be used by many different Claude applications, evolved and versioned on its own schedule, benefits enormously from exactly that ceremony. Get this backwards — over-engineer the one-off, under-engineer the shared capability — and you'll feel it later, either as wasted setup effort or as five different apps each hand-rolling their own slightly-different integration to the same underlying service.

The Model Context Protocol (MCP) is an open standard for exposing capabilities to any MCP client. Its defining value proposition is build-once, reuse-everywhere: an MCP server authored once is usable by many different Claude applications and clients, and — this is the part people miss — it's maintained on its OWN release cycle, independent of any single app that consumes it. Compare that to a direct API integration, where the integration code is embedded in, and tightly coupled to, one specific application. If the underlying service changes, every app with its own hand-rolled integration has to update separately; an MCP server updates once, and every client benefits.

MCP exposes three kinds of primitives to a connecting client, and it's worth knowing all three by name because questions will test whether you can tell them apart:

Once a client connects to one or more MCP servers, the tools from ALL of them become available simultaneously, alongside any of the client's own built-in or directly-defined tools. This is exactly why capability bloat (3.1) matters even more once MCP is in the picture: connecting to a general-purpose MCP server can hand your agent a much larger tool surface than it needs, and the least-privilege discipline from 3.1 applies just as much to MCP-sourced tools as to hand-written ones.

An MCP server has to physically run somewhere and communicate somehow, and MCP supports two transport models depending on where that server lives relative to its client.

• •stdio — for a local subprocess. The client launches the server as a child process on the same machine and talks to it over standard input/output. Simple, fast, and appropriate when there's exactly one client on the same box as the server — think a developer's local tool integration.
• •Streamable HTTP / sockets — for a remote, multi-client server. The server runs independently, reachable over a network, and many different clients can connect to it at once. This is the shape you want when the server genuinely serves multiple consumers, potentially from different machines entirely.

The choice mirrors the same reuse question from 3.4.1, one level down: a stdio server is inherently single-client and local, which is fine for a personal or single-app integration, but doesn't scale to "many apps reuse this server" the way the build-once-reuse-everywhere pitch implies. If you genuinely want multiple applications sharing one server instance, Streamable HTTP is the transport that makes that real, and it opens up a production concern advanced MCP topics cover in more depth: a remote server serving many clients has to decide whether it's STATEFUL (tracking per-client session state across requests) or STATELESS (treating each request independently, which scales more simply behind a load balancer).

3.4.3 raised the stateful-vs-stateless question as a forward-reference — worth naming, but not yet worked through. It deserves a full pass, because it's the difference between an MCP server that quietly falls over under real load and one that doesn't, and the exam expects you to reason about WHY, not just recite the two labels.

Start with what "stateful" actually means for a server process. A stateful MCP server holds session state — in-progress operation state, conversation-scoped context, per-client cached data — in its own memory, tied to a specific client connection. That's a completely ordinary thing for a server to do, and for a single client it costs nothing: the server remembers what it needs to remember, and there's no ambiguity about which memory belongs to which caller, because there's only one caller. The trouble starts the moment you try to run more than one instance of that server behind a load balancer to handle more traffic. If client A's session state lives only in server instance #2's memory, then every subsequent request from client A has to be routed back to that exact instance — a load balancer has to implement "sticky sessions," pinning each client to the server that already knows about it. That's a real operational constraint: it complicates deployment, complicates failover (if instance #2 dies, client A's state is just gone), and it caps how simply you can scale horizontally, because adding capacity means adding instances that can't actually share the work of an existing client's session.

A stateless server sidesteps the whole problem by design: every request is self-contained. The server doesn't need to remember anything about the caller between requests, because whatever it needs is either included in the request itself or fetched fresh from an external, shared store. Any instance behind the load balancer can handle any request from any client, because no instance is privileged with memory the others lack. This is what "scales more simply" actually means in concrete terms — not that stateless servers are magically faster, but that you can add capacity by adding identical, interchangeable instances with no coordination problem between them.

Now connect this to a concrete integration decision, because that's where the exam will actually test it. An MCP server backing a single-user local dev tool — a developer's own machine, one client, stdio transport or a lone Streamable HTTP connection — can be built stateful without a second thought. There's exactly one caller. There's no other server instance to route to. The entire sticky-session problem doesn't exist, because the condition that creates it (multiple instances, multiple clients, ambiguity about which instance knows what) never arises. Building it stateless anyway wouldn't be wrong, but it also wouldn't buy anything — you'd be paying design complexity for a scaling property you don't need.

Flip the scenario: the same MCP server is now the backend for a multi-tenant SaaS product serving thousands of concurrent agent sessions, one process fronted by many load-balanced instances to handle that volume. If it's stateful in the naive sense — session state sitting in whichever instance happened to handle the first request — you're now forced into sticky routing for every single tenant, your failover story is broken (an instance restart silently drops every session it was holding), and your ability to add capacity is hobbled by the coordination problem described above. The fix is one of two shapes: either redesign the server to be genuinely stateless (each request carries everything needed, or reconstructs its state from a shared source), or keep a stateful design but externalize the session state to something every instance can read and write — a shared cache like Redis is the canonical choice. Either path decouples "which instance handles this request" from "which instance remembers this client," which is exactly the coupling that broke the naive stateful design at scale.

It's tempting, once you've learned how good MCP is, to reach for it everywhere. Resist that instinct. A direct API or CLI integration — calling a service's REST API or command-line tool straight from your code, with no protocol layer in between — is the RIGHT choice, not a lesser fallback, when the integration is a one-off, app-specific need where a standard protocol adds no leverage. If exactly one application will ever call this capability, and no one is asking for it to be shared, wrapping it in MCP's server/client machinery adds ceremony that buys you nothing: no other app to share the maintenance burden with, no independent release cycle anyone benefits from, just extra moving parts.

Think of it like the difference between publishing a library on a package registry and writing a private helper function in your own codebase. If nobody else will ever import it, publishing it as a versioned package is pure overhead — you'll spend more time maintaining the packaging than you saved by having it. The helper function, kept local, is the right level of engineering for a need that stops at your app's boundary.

The third mechanism is qualitatively different from the first two, and the distinction matters more than it might first appear. MCP and direct API/CLI both connect Claude to a deterministic-ish CAPABILITY — call this function, get that data back. Agent-to-agent delegation is for when the thing on the other end is itself an autonomous AGENT — something that reasons, makes its own choices about how to proceed, and might itself use tools, retrieve data, or call further agents to get the job done.

The deciding question here isn't reuse — it's autonomy. If you're delegating "go figure out the best flight itinerary for this trip, using whatever research you need to do," you're handing off a GOAL to something that will reason its own way through it, not invoking a single well-defined operation with a fixed input/output contract. That's agent-to-agent delegation: one agent treats another as a unit of delegated reasoning, not as a function call with a predictable shape. Choosing agent-to-agent when the remote side is actually a simple deterministic function is over-engineering in the opposite direction from the MCP trap in 3.4.4 — you don't need to hand off a goal to something that only ever does one predictable thing.

Everything in this lesson so far has answered one question: mechanically, how does Claude reach a given CAPABILITY — MCP, direct API/CLI, or agent-to-agent? There's a second, related, but genuinely distinct question the exam expects you to be able to answer, and it's easy to miss precisely because it sounds similar: mechanically, how does a request reach CLAUDE at all — and once it does, which vendor relationship actually serves the model call underneath it? Conflating these two questions is a real and costly mistake, because the constraints deciding the second question are frequently organizational and contractual rather than technical, and they can override an otherwise-correct answer to the first. You can pick MCP for exactly the right reasons — a shared, independently-maintained capability — and still ship the wrong integration if you never asked which cloud relationship the client actually needs underneath it.

The clean way to hold all of this is as three distinct layers stacked on top of each other, each answering a different question about how a human or system actually ends up talking to a model.

The first two layers are the ones you've already built intuition for across this course. An entry point like Claude Code is itself built on a build-time interface — the Agent SDK, specifically, in Claude Code's case — while a custom application might be built on the direct API, one of the language SDKs, or MCP, depending on the reuse-and-maintenance calculus from earlier in this lesson. What hasn't been named explicitly until now is the third layer, and it answers something the first two don't: which company's infrastructure, compliance boundary, and billing relationship does the request actually run through once it leaves the client? Two organizations can build the IDENTICAL entry point on the IDENTICAL build-time interface — same Claude Code setup, same SDK calls, same MCP servers — and still need to land on entirely different delivery routes, because the delivery-route decision is inherited from commitments the client made long before this integration existed. For some clients, this is the single most consequential decision in the whole engagement, and it has nothing to do with which model tier they picked.

That last point is worth sitting with, because it's exactly why this layer is easy for an architect to underweight: the deciding question is never "which delivery route gives us the smartest model," because the answer to that question is always "they're identical." An architect focused only on model tier and build-time interface can get every other part of the design right and still hand a client an unusable answer, because the delivery-route decision never got made explicit as its own step. The deciding question here has the same shape as the reuse-and-maintenance question that decided MCP vs. direct API/CLI earlier in this lesson, just aimed one layer up: which cloud/vendor relationship does this client already have compliance, billing, and identity commitments to — and does routing through that existing relationship save more than it costs to set up something new?

Here's a full worked scenario to make that concrete. Consider a mid-size regional insurance carrier — call it Meridian Mutual — with roughly 4,000 employees, all of them already on Microsoft 365 E5 licensing, with every employee identity, group membership, and conditional-access policy managed in Azure AD (Entra ID), and an existing enterprise agreement with Microsoft covering the bulk of the company's cloud spend. Meridian wants to build an internal claims-adjuster assistant: an application built on top of Claude that helps adjusters draft coverage determinations by pulling policy documents and prior claim history. On pure model capability, calling Anthropic directly and calling Claude through Microsoft Foundry produce identical answers from identical models — there is no capability difference to adjudicate between the two routes. But three non-model factors make Foundry the right delivery route for Meridian specifically, and none of them would surface if the architect only asked “which model tier do we need.”

• •Identity integration. Meridian's IT security team requires every application touching claims data to authenticate through the company's existing Azure AD conditional-access policies — MFA enforcement, device-compliance checks, and the same group-based access rules already gating every other internal tool. Building on Foundry means the claims-adjuster assistant inherits that identity fabric automatically. Building against the Anthropic direct API instead means standing up a parallel authentication path with its own key management, its own audit trail, and its own gap in the conditional-access net IT already trusts — a new attack surface security has to separately review and approve.
• •Procurement and billing consolidation. Meridian's enterprise agreement with Microsoft already routes cloud spend through a single consolidated invoice that finance reconciles monthly against a pre-negotiated committed-spend discount. Routing Claude usage through Foundry lands it on that same invoice, under that same discount structure, with no new vendor contract for procurement to negotiate from scratch. Calling Anthropic directly instead means a brand-new vendor relationship, a new invoice finance has never seen, and a new set of terms legal has to review — real friction with a real dollar cost and a real timeline cost, even though the underlying model is unchanged.
• •Compliance boundary inheritance. Meridian's existing Microsoft enterprise agreement already covers the data-handling, audit, and retention commitments its compliance team negotiated for the rest of its Azure footprint — including the specific commitments that satisfy its state insurance regulators. Routing claims data through Foundry keeps that data inside a compliance boundary regulators have already reviewed and approved. Routing it to a different vendor means asking compliance to re-review a materially different data-handling arrangement before the assistant can go live, which can add months to a launch timeline for reasons that have nothing to do with the quality of the underlying model.

One more piece of vocabulary rounds out the picture, and it belongs here because it's a contractual data-handling concern that can directly gate which delivery route a client is even permitted to use. You've already seen BAA, HIPAA, GDPR, FedRAMP, and data residency elsewhere in this course as the regulatory vocabulary an architect needs. Two more terms complete that list: a DPA (Data Processing Agreement) is the contract governing how a data processor handles and protects personal data on a controller's behalf — typically required alongside GDPR compliance whenever a vendor processes EU personal data for a client. ZDR (Zero Data Retention) is a configuration or contractual option where the vendor does not retain input/output data beyond the immediate processing window — relevant for the most data-sensitive delivery-route decisions, since not every delivery route or model configuration supports it. Both terms matter here specifically because they're data-handling commitments, not model-capability features: a client whose regulatory posture requires ZDR, or a specific DPA covering a specific processing arrangement, may find that requirement easier to satisfy through one delivery route than another — if the client's existing AWS or Azure contract already includes a DPA covering that CSP's services, extending coverage to Claude via Bedrock or Foundry can be simpler than negotiating a new DPA directly with Anthropic, and the reverse holds if the client's most mature data-processing terms already sit with Anthropic.

You now have the full decision framework: reuse-and-maintenance profile decides MCP vs. direct API/CLI, and autonomy on the other end decides whether agent-to-agent is warranted at all. The fastest way to make this stick is to practice classifying real-sounding integrations against the framework rather than just memorizing the table.

Choosing the right protocol solves HOW Claude connects. The final lesson of this domain turns to what happens once everything is wired up and running in production: how do you observe it, and how do you justify the accuracy-latency-cost knobs you turn?