Choosing an integration mechanism: MCP, API/CLI, agent-to-agent

What you’ll be able to do

• Compare MCP, direct API or CLI tool integration, and agent-to-agent delegation by reuse, control, ownership and operational cost
• Select stdio or HTTP-based MCP transport from who runs the server and who must reach it
• Recognize when a capability should be a deterministic tool call rather than a delegated agent
• Account for security, versioning and failure handling at the integration boundary for each mechanism

What you need to know

Three mechanisms, three shapes of problem

• Direct API or CLI tools. You define tools in your application (through the Messages API's tool use, or as commands an agent runs in a shell such as Claude Code's) and your code calls the service directly. Maximum control, minimal moving parts. The integration lives in one codebase.
• MCP (Model Context Protocol). An open protocol through which a server exposes tools, resources and prompts to any compatible client: Claude Code, Claude apps, the Agent SDK, your own host. The capability is built once and reused by many clients, and the server's owners maintain it.
• Agent-to-agent. Your agent hands a goal to another agent, which plans, reasons and uses its own tools before returning a result. This can be a subagent in your own system or an independently owned agent reached across an organizational boundary.

The question is never "which is most modern?" It's who needs this capability, who owns it, and whether the other side needs to reason or just execute.

When a direct API or CLI tool is right

Pick direct integration when one application needs the capability, your team owns both sides, and you want tight control over latency, error handling and exactly what the model sees. A purpose-built tool that calls your order service and returns the three fields the agent needs is simpler to secure, test and observe than standing up a server. CLIs fit coding and operations agents that already work in a shell: a well-known CLI with good help text can be a perfectly good integration surface, and it brings its own authentication and audit behaviour. Watch out for overly broad shell access, though (see 3.1).

The cost shows up as reuse grows. When five teams each hand-code the same CRM integration into their agents, you have five auth implementations, five schemas drifting apart, and five places to patch.

When MCP is right

Pick MCP when a capability should be available to many clients or teams, when you want one place to own its security and evolution, or when you're consuming a capability a vendor or platform team already publishes as a server. Points that matter at Professional level:

• Transport follows deployment. stdio runs the server as a local subprocess of one client, which fits personal and developer tooling. An HTTP-based transport (Streamable HTTP) runs the server as an independent network service that many clients share. Moving to HTTP turns the server into a network service that needs real authentication and per-caller authorization.
• Primitives matter. Tools are model-invoked actions. Resources expose data the application can bring into context. Prompts are reusable templates. Don't force read-only reference data into tools when it's really a resource.
• Curate what you connect. A server may expose far more than a given agent needs. Connecting it doesn't mean exposing all of it (see 3.1 and 3.8).
• Third-party servers are supply chain. Tool descriptions and results from an external server enter your model's context. Vet servers, pin versions, and treat their output as untrusted input.

When agent-to-agent is right

Delegate to another agent when the task needs open-ended reasoning and tool use that you don't want to (or can't) reproduce: another team's agent with its own domain knowledge, tools and data access, or a specialist subagent that needs an isolated context. Conceptually, agent-to-agent integration means exchanging tasks and results rather than function calls: one agent describes a goal and its constraints, the other works on it, possibly over many steps, and returns an outcome. Industry protocols for cross-organization agent interoperability are emerging. Evaluate any specific one on its own documentation rather than assuming its guarantees.

The trade-offs are real. Results are non-deterministic and harder to test. Latency and cost compound across agents. Errors can propagate silently. Trust is harder to establish: you need to decide what authority the remote agent has, what data it may see, and how you'll verify what it returns. If the job is "look up the balance for account X," that's a deterministic API call, and wrapping it in an agent adds cost and unpredictability for nothing.

A practical decision sequence

1. Does the other side need to reason, plan or use its own tools? If not, use a tool (API, CLI or MCP).
2. Will several clients or teams need the same tool? If so, MCP, owned by whoever owns the capability. If not, a direct tool in your application.
3. If MCP: does it run for one local client or many networked ones? That decides stdio or HTTP, and with HTTP comes authentication and authorization.
4. If agent-to-agent: define the task contract, the authority you're delegating, timeouts and fallbacks, and how results are validated before you act on them.

Boundaries need contracts whichever mechanism you pick

Every mechanism needs versioned interfaces, structured error responses the model can act on, timeouts and retries with idempotency for side-effecting calls, and trace propagation (see 3.4). These are what make an integration operable, and none of them come free with the mechanism.

Key concept

Use a tool when the other side just executes, MCP when that tool should be shared and owned once across clients, and agent-to-agent only when the other side has to reason with its own tools, and then pay for it in contracts, trust and validation.

Questions describe a capability with a sharing pattern (one app, many teams, an external partner) and a nature (deterministic lookup versus open-ended task). Read both. Distractors put MCP everywhere, delegate deterministic calls to agents, or run shared servers over stdio.

Practice scenario

Build exercise — Write an integration decision record

Advanced · 40 min

What you’ll learn

• Applying the reason-or-execute and reuse tests to real capabilities
• Choosing MCP transport from the deployment model
• Specifying the contract an agent-to-agent handoff needs

1. List five capabilities your agents need. For each, record who consumes it, who owns the system behind it, and whether the other side must reason or only execute.

   • Why: These three facts decide the mechanism. The capability’s subject matter is usually a distraction.
   • You should see: Most capabilities landing as tools, a few shared enough for MCP, and at most one that needs agent-to-agent.

2. For each MCP candidate, choose stdio or HTTP transport and write the authentication and authorization approach the choice implies.

   • Why: Transport is a deployment and security decision, not a configuration detail.
   • You should see: Shared servers on HTTP with explicit per-caller auth, and local developer tools on stdio.

3. For the agent-to-agent candidate (or a hypothetical one), write the task contract: inputs, delegated authority, data shared, timeout, fallback, and how the result is validated before use.

   • Why: Delegation shifts reasoning across a trust boundary. The contract keeps that shift safe and testable.
   • You should see: A one-page contract that a reviewer from security could sign off on.

Exam traps

Wrapping every internal function in its own MCP server regardless of reuse

MCP pays off when a capability is shared across clients. For one application’s own integration, a direct tool is simpler to secure and run.

Delegating to another agent when a deterministic API call would do

Agents add latency, cost and non-determinism. If the other side only executes, call it as a tool.

Hard-coding the same integration separately in many clients instead of sharing it once

Duplicated integrations drift and multiply security work. Publish the shared capability once, typically as an MCP server.

Running a shared, multi-user MCP server over stdio

stdio serves one local client process. Shared servers need an HTTP-based transport and real auth.

Assuming an integration standard handles authorization and trust for you

Protocols define how to connect, not what each caller may do. You still design authentication, authorization and validation of results.

Ignoring interface versioning and failure contracts at the integration boundary

Unversioned interfaces and unstructured errors make integrations brittle. Define versions, structured errors, timeouts and idempotency.

Sources

• Model Context Protocol
• Claude Developer Platform Docs
• Anthropic, Claude Certified Architect – Professional Exam Guide v1.0 (July 2026)