What You Need to Know
Four mechanisms connect Claude to the systems around it. The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems. A direct API or SDK integration calls the model from one application's own code. A headless run embeds an agent in automation. In an agent-to-agent integration, one agent gives work to another agent. Each mechanism serves one consumer pattern. A consumer is whoever uses the integration.
This lesson uses one made-up example throughout: a gym chain. Its class-booking system must serve front-desk staff in claude.ai, developers in Claude Code and an API-based member app. A nightly agent updates waiting lists, and one renewals app drafts letters. Like most real organisations, the gym mixes mechanisms. It uses MCP for the shared capability, a headless run for the scheduled job and a direct call for the one-off step.
MCP Collapses M×N to M+N
Without a standard, each pair of an application and a system needs its own custom integration. That means M times N builds. MCP's own analogy is a USB-C port: one standardised connection for every pair. Build a server once and any MCP client uses it. Clients discover its tools and resources dynamically. Nothing is hard-coded. The number of builds becomes M plus N.
The cue is reuse: one MCP server serves all three gym clients. A server for one consumer that will never share it is infrastructure without a beneficiary. It adds an ongoing auth and operational burden and gives no reuse.
MCP Transports
The MCP specification defines two standard transports. In stdio, the client launches the server as a subprocess and communicates over stdin and stdout. This transport is local and single-client, and both sides run on the same machine. In streamable HTTP, the server runs as an independent process. It handles multiple clients over one HTTP endpoint. It has optional server-sent events for streaming. This transport is remote and shared, and the OAuth authorisation model from objective 3.2 applies to it.
The gym's shared booking server needs streamable HTTP, which is still MCP. "We need HTTP, so we can't use MCP" is the deliberate confusion that the exam includes. Streamable HTTP is an MCP transport. So the choice between transports is a choice of deployment topology (where the server runs and how many clients share it), not of protocol.
Direct Integration and Headless Runs
A direct integration controls its whole loop: the application calls the model, executes tools and handles results in its own code. A direct integration gives the lowest overhead and full control, but it gives no reuse. The renewals app is the only consumer of its letter step, so a direct call fits. Once a second surface or team appears, a direct integration is wrong. Each surface or team would build the same connection code again.
For a headless run, the Agent SDK is a library that runs the same agent loop as Claude Code. The CLI runs non-interactively as a subprocess with parsed output. The cues are "runs nightly", "in CI" and "unattended". The gym's waiting-list job is a headless run. A script consumes its output, and no human is in the loop.
Agent-to-Agent: Does the Counterpart Decide?
The test is whether the counterpart reasons. Subagents run in their own fresh context. Each subagent has its own instructions and restricted tool set. Intermediate work stays inside the subagent. Only the final result returns to the parent. This design gives context isolation and lets subagents run in parallel, inside one system. A peer agent service extends the idea to a system that a different owner runs. A peer agent service is a separately owned system with its own tools and judgement.
A supplier's agent that ranks the gym's repairs would reason. The gym's door-access service only issues entry codes. A fixed, fully specified operation is a tool, and a plain tool call is right. Compared with a call that does the same job, an agent wrapper adds tokens, latency and a new point of failure.
| Mechanism | Selection cue | Wrong when |
|---|---|---|
| MCP server | Capability reused across surfaces, teams, clients | One consumer, no sharing ambition |
| Direct API/SDK | One application, full control, custom loop | A second surface or team appears |
| Headless (SDK/CLI) | Pipelines, CI, cron: a script consumes parsed output | A human interactive surface is the consumer |
| Agent-to-agent | The counterpart reasons and decides for itself | The counterpart executes a fixed operation |
In the exam
In these selection questions, the right answer depends on the number of consumers and surfaces in the question, not on how sophisticated the mechanism is. Answers that mix mechanisms are often right. In an unattended job, streaming and chat surfaces are wrong options wherever they appear. They serve a person who is watching, and nobody is watching.
Count the Consumers
This objective's typical wrong option is an impressive mechanism in a case where the boring mechanism is right. Before comparing mechanisms, count: how many consumers, how many surfaces, who owns each side, and does the other side make decisions? The question always contains the numbers.
Exam Traps
Building an MCP server for a bespoke, single-consumer integration nobody will reuse
The M-plus-N economics only give a saving when there are multiple Ms. With one consumer, the server adds permanent infrastructure, more authentication to secure and operational burden, and gives no reuse. Make the direct call instead.
Rejecting MCP because the deployment needs HTTP, or treating stdio as the only real MCP
Transports are deployment topology within MCP: stdio for local subprocess servers, streamable HTTP for remote shared ones. The protocol is the same on both. Keep MCP and choose streamable HTTP for a remote, shared server.
Delegating to a peer agent whose task is a deterministic, fully-specified operation
If the other side makes no decisions, it is a tool. The agent wrapper adds tokens, latency, and a new point of failure over the plain tool call that does the same work.
Adding interactive features, such as token-by-token streaming into a chat surface, to a job that runs nightly in a pipeline
The consumer is a script parsing output, not a human watching tokens. Unattended cues (nightly, CI, cron) point to a headless run, and chat features for a person add cost and benefit nobody.
Practice Scenario
A company needs: (a) its internal ticketing system available to Claude in claude.ai for support staff, in Claude Code for engineers, and to an API-based triage service; (b) a nightly job where an agent summarises the incidents of the day into a report; (c) a bespoke invoice-OCR step used by exactly one billing pipeline. Which integration design fits?
Build Exercise
Consumer-Pattern Worksheet for Three Integrations
What you'll learn
- How to count consumers, surfaces, and owners before choosing a mechanism
- How to apply the test of whether the counterpart makes decisions
- How to assign MCP, direct, headless, or agent-to-agent with a written argument
- How to stress-test an assignment against plausible growth
- List three integrations from your environment — or design them: one shared capability, one automated job, one bespoke step
Why: The three typical cases use all four mechanisms and force at least one mixed answer, which is how real organisations’ systems look.
You should see: Three one-line integration descriptions with visibly different consumer patterns.
- For each integration, count the consumers and surfaces today and plausibly within a year; note who owns each side
Why: The right answer follows consumer counts, not mechanism sophistication — and ownership decides whether agent-to-agent even applies.
You should see: A count per integration: consumers now, consumers in a year, surfaces, and an owner per side.
- Apply the agent-to-agent test to each: does the counterpart make decisions, or execute fixed operations?
Why: The test separates delegation from invocation — and it eliminates the most expensive wrong answer in one question.
You should see: A one-word verdict per integration: reasons, or executes.
- Assign a mechanism per integration — MCP with a named transport, direct API, headless run, or agent-to-agent — with the consumer-pattern argument written out
Why: The written argument is the exam skill: the pattern decides the mechanism, and the sentence proves that the pattern was identified.
You should see: Three assignments, each with a one-sentence argument naming consumer count, surface count, or the verdict on whether the counterpart decides or executes.
- Stress-test the cheapest assignment: what specifically would have to change — new consumer, new surface, new owner — to flip it to MCP, and how much rework that flip would cost
Why: Direct integration is right until the reuse cue appears; knowing in advance what would require the change is what makes the cheap choice safe.
You should see: A named condition for the change and a rough estimate of the rework when it happens.
Sources
- What is the Model Context Protocol (MCP)? — Model Context Protocol
- MCP Transports — Model Context Protocol
- Agent SDK overview — Anthropic
- Subagents in the SDK — Anthropic
- Claude Certified Architect Professional Exam Guide (v1.0) — Domain 3 — Anthropic