AnthropicClaude Certified Architect – Professional2026-103.7 Evaluate connection protocols and select the appropriate integration mechanism (MCP, API/CLI, agent-to-agent)
Weigh four integration mechanisms per connection
Completed by the knowledge check
Learning objective
Compare MCP, direct API or custom-tool integration, CLI invocation, and agent-to-agent delegation on reusability, identity propagation, observability, failure isolation, and control.
Core idea
For an architect selecting enterprise integrations, the useful question is where each connection puts authority and operational responsibility. A shared capability, an application-owned operation, a shell command, and an independently operated agent can all contribute to one workflow. They need not use the same integration mechanism.
Choose per connection. Model Context Protocol (MCP) standardizes a capability interface; a direct custom tool keeps dispatch in application code; a command-line interface (CLI) reuses an executable in the agent’s working environment; agent-to-agent delegation transfers a task to another agent’s execution system. None of those choices automatically establishes end-user identity, business authorization, or acceptable results.
How it works
Compare what you actually hand over
With Messages API client tools, you supply tools definitions with name, description, and input_schema. A returned tool_use requests execution by your application. You choose which backend to call and which policy checks precede it. The model-visible tool and the backend API are separate interfaces: the tool can combine several backend operations into one business action.
With MCP, you connect a host to a server that exposes capabilities. Claude Code supports remote HTTP servers and local stdio processes. Reuse comes from implementing a contract that multiple compatible hosts consume. Check host support rather than treating MCP compatibility as a guarantee that every host handles every capability identically; see 3.7.2.
With a CLI, Claude Code uses its shell capability to invoke an installed program. Anthropic recommends established CLIs such as gh, aws, and gcloud for external services and documents learning unfamiliar commands through --help. You reuse the executable and its operational conventions, while accepting a dependency on the runtime environment in which it runs.
With external agent delegation, you assign an outcome rather than prescribing every operation. The receiving system chooses its internal execution. Agent2Agent (A2A) is one protocol for this relationship, with tasks and result artifacts. A network endpoint alone does not make something an agent: a deterministic lookup remains a tool even when another company operates it.
Trace identity separately from the payload
For a direct tool, identify the credential the application executor presents to the backend; see 1.2.2 for resolving tool_use.input against authenticated application state.
For MCP, identify both the credential the host presents to the server and the identity the server uses downstream. For a CLI, identify the account selected by that command’s environment and credential configuration. For A2A, the Agent Card declares security requirements, credentials travel in binding-appropriate headers or metadata, and the server authorizes the authenticated caller under its own policies.
Record which principal each credential represents, and use the principal mapping in 3.2.1 to explain any user-to-service-account transition.
Locate observable failure and control
For a direct tool, correlate the model’s tool_use.id with the returned tool_result.tool_use_id, then with your backend operation record. For a CLI, preserve the command’s outcome alongside the invoking job; a successful Claude answer alone does not prove that the command changed the intended service. For MCP, join host observations with server-side records. For A2A, keep the remote task’s id, status, and artifacts associated with the original request.
These identifiers expose different boundaries. A direct executor gives you an interception point before calling the backend. A remote MCP service creates a shared availability dependency. A stdio server adds a subprocess dependency to its host. A CLI failure can arise before reaching the service because the binary or credentials differ. A remote agent can accept work yet fail to deliver an acceptable artifact.
Key distinctions and trade-offs
Use the following comparison to identify the operational price of each choice:
| Dimension | MCP | Direct API/custom tool | CLI invocation | External agent delegation |
|---|---|---|---|---|
| Reusability | Capability contract for compatible hosts | Share a library or service deliberately | Share executable and command conventions | Share a task interface and acceptance rules |
| Identity | Host-to-server and downstream identities | Application executor selects credentials | Command’s runtime identity | Authenticated caller plus remote agent identity |
| Observability | Join host and server records | Join tool call and backend records | Join job, command, and service records | Join local request, task state, and artifact |
| Failure isolation | Depends on local process or remote service | Depends on executor and backend placement | Depends on process and shell environment | Separate execution with a remote lifecycle |
| Control | Host exposure and server implementation | Application mediates each operation | Harness permissions and backend permissions | Local admission and acceptance; remote internals remain remote |
A direct integration can be reused; it does not force every client to rebuild the backend. MCP makes the host-facing interface portable, which can reduce repeated adapters. Neither protocol choice alone provides process isolation: an in-process custom tool shares its host’s lifecycle, while a separately deployed executor can isolate it.
Architecture / decision scenario
A retail group needs store-local diagnostics for electronic shelf-label controllers, a refund service with a two-second response target, an engineering shell workflow, and an external assortment-planning agent whose work takes twenty minutes. The platform lead proposes remote MCP interfaces for everything.
The architect chooses an approved stdio MCP package for shelf-label diagnostics because it must run beside each store’s local controller. The same capability contract is reusable across the store fleet, while each host operates its own process and credentials. The refund executor remains a direct custom tool because it must perform the application’s authorization and approval checks before a write; adding MCP would not remove those checks and would add an operational dependency to the measured response path.
Engineers retain an established CLI with scoped accounts and Claude Code permission rules. The assortment task uses external delegation because the supplier owns planning and returns a task result rather than a fixed lookup. Local records correlate tool calls, commands, and remote task IDs with the business request.
The alternative is plausible because one interface simplifies training. It loses on operational fit: the shell workflow already has an executable, the refund path needs local mediation, and assortment planning needs task tracking. The architect owns the connection decisions; each service owner owns its execution and failure handling. The deployment places diagnostics and refund execution in separate failure domains: a failed diagnostics process must leave refund authorization available. Store operations owns the local process and controller access; the application records unavailable diagnostics as incomplete.
Common exam traps
- Selecting one mechanism for an entire organization.
- Treating a model-supplied account identifier as authenticated identity.
- Assuming MCP centralizes every credential and audit record automatically.
- Assuming direct tools cannot share code or services.
- Treating a remote fixed-function API as autonomous delegation.
- Equating a successful connection or accepted task with an accepted business result.
What to remember
Compare the location of reusable contracts, authenticated authority, observable outcomes, and execution control. Choose the connection that puts each responsibility with an owner able to operate it. Then verify identity and failure behavior across that specific boundary.
Knowledge check
A retail group’s customer-service application lets Claude issue refunds. Before any refund write, the application must check the order’s state and the agent’s approval limit, and the refund path has a two-second response target. Only this application issues refunds, no other host needs the operation, and its executor already implements these checks. Which integration preserves that mediation with the least additional infrastructure?
A logistics platform buys freight quotes from a carrier that markets its endpoint as a “quoting agent”. Given an origin, a destination, a weight and a date, the endpoint returns one rate record; it does no planning, asks no questions and keeps no task of its own. How should the architect integrate it?
In a platform team’s Claude Code session, Claude runs gcloud to change a Cloud Storage bucket’s retention policy. An auditor asks which principal Google Cloud authorized for that change. Which identity must the record establish?
gcloud command’s environment and credentialsReferences
- Anthropic, Tool use with Claude
- Anthropic, Define tools
- Anthropic, Connect Claude Code to tools via MCP
- Anthropic, Best practices for Claude Code
- Agent2Agent, Protocol specification, version 1.0.0