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. Agent-to-agent hands work to another agent. Each serves one consumer pattern, a consumer being whoever uses the integration.
Take a gym chain. Its class-booking system must reach 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 estates, the gym mixes mechanisms: MCP for the shared capability, a headless run for the scheduled job, a direct call for the one-off step.
MCP Collapses M×N to M+N
Without a standard, each application-system pair needs its own custom integration: 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 build-out falls to 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: standing auth and operational burden for no reuse.
MCP Transports
The MCP specification defines two standard transports. In stdio, the client launches the server as a subprocess and speaks over stdin and stdout: local, single-client, same-machine. In streamable HTTP, the server runs as an independent process handling multiple clients over one HTTP endpoint, with optional server-sent events for streaming. It 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 planted confusion. Streamable HTTP is an MCP transport, so the choice between transports is deployment topology, not protocol.
Direct Integration and Headless Runs
A direct integration owns its whole loop: the application calls the model, executes tools and handles results in its own code. That gives the lowest overhead and full control, but no reuse story. The renewals app is the only consumer of its letter step, so a direct call fits. Once a second surface or team appears, direct is wrong: each would rebuild the same wiring.
For a headless run, the Agent SDK runs the same agent loop as Claude Code as a library. The CLI runs non-interactively as a subprocess with parsed output. The cues are "runs nightly", "in CI", "unattended". The gym's waiting-list job is one: a script consumes it, with no human 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 with its own instructions and restricted tool set. Intermediate work stays inside; only the final result returns to the parent. That buys context isolation and parallelism inside one system. A peer agent service extends the idea across an ownership boundary: 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. An agent wrapper adds tokens, latency and a new point of failure over a call that does the same job.
| 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 keyed answer follows the number of consumers and surfaces in the stem, not the sophistication of the mechanism, and mixed answers are often keyed. In an unattended job, streaming and chat surfaces are distractors wherever they appear: they serve a person watching, and nobody is.
Count the Consumers
The impressive mechanism planted where the boring one is right is this objective's signature distractor. Before comparing mechanisms, count: how many consumers, how many surfaces, who owns each side, and does the far side make decisions? The stem always contains the numbers.
Exam Traps
Standing up an MCP server for a bespoke, single-consumer integration nobody will reuse
The M-plus-N economics only pay when there are multiple Ms. One consumer means the server is standing infrastructure, auth surface, and operational burden purchased for no reuse — the direct call is cheaper on every axis.
Ruling MCP out 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 — the confusion is planted, not real.
Delegating to a peer agent whose task is a deterministic, fully-specified operation
No decisions on the far side means it is a tool. The agent wrapper adds tokens, latency, and a new failure surface over the plain tool call that does the same work.
Adding interactive machinery — streaming, chat surfaces — 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) key headless runs, and interactive features are cost without a beneficiary.
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 does-the-counterpart-decide test
- 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 archetypes exercise all four mechanisms and force at least one mixed answer, which is how real estates 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 keyed 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: mechanism follows pattern, and the sentence proves the pattern was read.
You should see: Three assignments, each with a one-sentence argument naming consumer count, surface count, or the decide-versus-execute verdict.
- 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 the flip condition in advance is what makes the cheap choice safe.
You should see: A named flip condition and a rough rework estimate for the day it arrives.
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