Integration Protocols: How Claude Reaches the Outside World

A Claude system on its own is a model in a loop. It becomes a platform the moment it can reach things: an order database, a payments API, a document store, another team’s service. Domain 3 is the largest slice of the Professional blueprint. This chapter opens it with the question every integration starts with — not how do I call this thing, but through which mechanism should Claude reach it, and why. Get the mechanism right and the rest of the arc (RAG, security, observability) has something clean to stand on. Get it wrong and you spend the next year gluing brittle one-offs together.

What “integration” means for a Claude system

Every external capability a Claude system uses arrives the same way at the model: as a tool. The Foundations tool chapter covered what a good tool looks like from the model’s side — a clear name, a tight schema, structured errors. Integration is the question one layer down: where does that tool actually live, and how does your system connect to the service behind it?

That’s not a cosmetic choice. The same “look up an order” capability can be a function defined inline in your application, a command-line call, a request to a remote HTTP API, or a tool served by a separate process over a standard protocol. Each option makes different promises about reuse, coupling, security boundaries, and who owns the code. The architect’s job is to match the mechanism to the need, and to keep the whole surface small enough to reason about.

When you even need a protocol — and when you don’t

Reach for the simplest integration that does the job. Say your agent needs one function that reads a value from a database your application already talks to. You don’t need a protocol at all: you define a tool, its handler runs your existing query, and you’re done. Protocols earn their complexity only when there’s something to share or decouple.

Three signals say a heavier mechanism is worth it. Reuse across applications: the same capability is needed by more than one Claude system, or by systems some other team owns. A trust boundary: the capability should run in its own process with its own credentials, so a bug or a compromise is contained. Independent ownership and lifecycle: the team that owns the order service should be able to ship changes to its tools without a coordinated release of every consumer. Absent all three, a plain in-process tool is not a shortcut, it’s the correct design, and the exam rewards recognizing that.

The landscape of integration mechanisms

There are three mechanisms an architect chooses among. They are not competitors so much as fits for different shapes of problem.

MCP — the Model Context Protocol. MCP is an open standard for exposing tools, resources, and prompts from a server that any MCP-capable client can connect to. Its whole reason to exist is the N×M problem: without a standard, connecting N applications to M capabilities means building N×M bespoke integrations, and every new capability means re-integrating it everywhere. With MCP you write the capability once as a server, and every client speaks it for free. The mechanics are the subject of the MCP series and ccd-foundations chapter 11: building a server, defining its tools, serving over stdio or Streamable HTTP. Here the point is architectural. Choose MCP when a capability is reusable across applications or teams, or when it deserves its own process and credentials. A shared “search the product catalog” server that three different assistants all use is the textbook fit.

Direct API and CLI integration. Sometimes the capability is a single service your application already owns, and wrapping it in a protocol buys you nothing. Here the tool’s handler simply calls an HTTP API, runs a CLI command, or invokes a library function in-process. This is the lightest option: no extra process, no protocol version to track, no discovery step. The cost is that the integration is local to this application — nobody else can reuse it without copying it. Choose direct integration when the capability is app-specific, called from exactly one place, and has no reason to live behind a boundary. A handler that reads a config value or hits your own internal endpoint belongs here.

Agent-to-agent connection. The third mechanism is not connecting Claude to a service but to another agent. This is the multi-agent territory from Foundations, seen as an integration decision: a coordinator delegates a scoped task to a subagent, or one system hands work to another autonomous system that reasons and acts on its own. The distinction that matters is that you’re integrating with something non-deterministic — it decides its own steps. So the contract is a task and a result, not a function signature and a return value. Choose agent-to-agent when the work genuinely needs another agent’s judgment, not merely another function call. Wrapping a deterministic lookup as a whole agent is over-engineering; handing off “investigate why this shipment is late and summarize the cause” to a specialist is the real fit.

A quick way to hold the three apart: direct integration connects Claude to your service, MCP connects many clients to a shared capability, and agent-to-agent connects Claude to another decision-maker.

The hazard the exam presses hardest: capability bloat

Once integration is easy, the failure mode flips from “can’t reach anything” to “reaches too much.” Capability bloat is piling every conceivable tool onto one agent. It’s the anti-pattern the exam sets its traps around, and it hurts in two independent ways.

The first is selection quality. A model chooses a tool by reading the descriptions of everything available to it. Twelve well-named tools is a menu it can reason over; eighty is noise. As the tool count climbs, the model picks the wrong tool more often, or hesitates, or calls tools it didn’t need. It’s the same degradation-under-clutter that motivates keeping subagent tool sets tight. More tools does not mean a more capable agent past a point; it means a less reliable one.

The second is the attack surface. Every capability an agent holds is something an attacker can try to make it misuse through a prompt-injection or a poisoned document. An agent that can only read the catalog can, at worst, be tricked into reading the catalog. An agent that also holds delete, refund, and email-send is a far richer target, and the blast radius of a single successful manipulation is everything those tools can do. Bloat widens that radius for free.

Both problems point the same way: least privilege. Give each agent the smallest set of capabilities its job requires, and no more. When you catch yourself adding a tool “in case it’s useful,” that’s the instinct to resist. The right home for a rarely-needed capability is a scoped subagent that holds it, invoked only when needed, rather than a permanent fixture on the main agent’s belt. Least privilege is simultaneously a reliability decision and a security decision, which is why it recurs through the rest of this arc.

Deciding the bookshop platform’s integration mesh

Now make the call for our platform. It has a customer-facing assistant, an internal operations assistant, and a batch review job, and among them they need: product catalog search, order lookup, refund processing, help-article retrieval, and customer-data deletion. Which mechanism gets each?

Shared MCP servers for the capabilities more than one application needs and that deserve their own boundary. Catalog search is used by every assistant and belongs to the catalog team — an MCP server, written once, consumed everywhere. Order lookup is the same story: shared, owned by the orders team, served over MCP. Putting these behind MCP means the orders team ships tool changes on its own cadence. And the credentials to hit the order database live in that server’s process, not scattered across every client.

A guarded MCP server, but not on every agent, for the dangerous capabilities. Refunds and customer-data deletion are irreversible and touch money and PII. They can live on an MCP server too, but least privilege says the customer-facing assistant must not hold them at all. A customer-visible agent that can issue refunds is a prompt-injection jackpot. Those tools go only to the operations assistant, behind human approval, which is exactly the escalation discipline this series will formalize under governance.

Direct, app-local tools for the rest. Help-article retrieval in this platform is really a RAG query against a vector store the assistant application owns. No other consumer, no separate lifecycle, so it’s a plain in-process tool, not a protocol. That RAG pipeline is the whole next chapter. And an internal reporting call the ops assistant makes to one endpoint nobody else uses stays a direct API handler.

No agent-to-agent boundary is warranted here yet: the assistants coordinate through one supervisor with scoped subagents, which is orchestration inside one system, not integration between two. If a separate fraud-investigation system with its own judgment appeared, that handoff would be the agent-to-agent case.

The shape that falls out is deliberate: a small mesh of shared servers for what’s reused and boundaried, local tools for what isn’t, dangerous capabilities scoped to exactly the one agent that should hold them, and no agent carrying a tool it doesn’t need.

Final thoughts

Integration is a matching problem. Direct API and CLI tools are the default for app-specific capabilities; MCP is the answer when a capability is reused across applications or wants its own process and credentials; agent-to-agent connection is for handing work to another decision-maker, not another function. Layered over all three is one discipline the exam tests relentlessly — least privilege — because capability bloat degrades both the model’s tool selection and the system’s security at once. Decide the mesh the way we did for the bookshop: share what’s shared, boundary what’s dangerous, keep the rest local, and give every agent the smallest belt that does its job.

Next: the RAG pipeline, end to end — chunking, embeddings, indexing, and grounded generation, run against the platform’s real corpus.