Home › Study guides › CCAR-P › Domain 3 › Lesson 3.7

CCAR-P · Domain 3 · 19% of the exam · Lesson 3.7 · 21 min read

MCP, API, CLI or agent-to-agent: choosing the integration mechanism

How to choose MCP, a direct API tool, a CLI or agent-to-agent (A2A) for each connection, by ownership, reuse, auth, state, latency and audit.

Written against objective 3.7 of the official CCAR-P exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

3.7.1 Four connections, four different shapes

Thistlecombe Retail Group runs department stores and a chain of outdoor-equipment shops, and its merchandising team is getting a Claude-based assistant. A merchandiser will ask it which camping lines are overstocked in the north and what to mark down. To answer, the assistant needs live stock from StockLedger, the in-house inventory system, and a price recommendation from Veltaro, an outside vendor whose pricing-optimisation agent the group already pays for. When a merchandiser approves a markdown, the assistant saves it to a proposal store for the pricing team.

Anneliese, the solution architect, hears two proposals at the first design review. One engineer wants to "make everything MCP, because it's the standard"; another wants plain API calls everywhere. Both pick one mechanism for the whole company, and both break somewhere. Meanwhile Kwabena, who runs platform engineering, says the assistant's engineers want Claude Code to use his team's existing command-line tools: rollout for deployments and lakeq for data queries.

There are four ways to connect an AI system to something else. MCP (the Model Context Protocol) publishes a capability once, as a server that many AI applications can use. A direct API integration defines a tool in your own code that calls your own service. A CLI (command-line interface) integration lets an agent working in a shell run tools your teams already use. Agent-to-agent delegation hands a whole task to an agent that someone else owns, and the Agent2Agent (A2A) protocol is the open standard for it.

3.7.2 MCP: publish a capability once, reuse it everywhere

Start with StockLedger, because it shows the problem MCP was built to solve. A store-operations assistant, a customer-service agent and a supply-chain planner want stock levels too. If each team writes its own integration, Thistlecombe ends up with four schemas for one question, four sets of credentials, four log formats and four places to fix when StockLedger changes. The answers drift apart as well, because each team describes the tool and handles edge cases its own way.

MCP is an open standard for connecting AI applications to external systems, built as client and server. An MCP server exposes capabilities: tools the model can call, resources that supply context such as records or files, and prompts, which are reusable templates. An MCP host is the AI application, such as Claude Code or Claude Desktop, and it opens one MCP client connection per server. Think of a warehouse that builds one standard loading dock instead of a private road to every shop: any truck built to the standard can use it.

A local server runs on the host's machine over standard input and output (stdio), usually for one client, and takes its credentials from its environment. A remote server runs as a service over Streamable HTTP for many clients; when it needs authorisation, the MCP specification uses OAuth 2.1, so each client presents an access token. Anneliese chooses a remote StockLedger server, run by the inventory team, with read-only tools such as get_stock_level and get_inbound_shipments. Whose identity that token carries is a separate design question.

The assistant is built on the Claude API, where the MCP connector lets a Messages API request use a remote MCP server without you writing an MCP client. Look at the https URL, the authorization_token your application obtains and refreshes, and the default_config that switches every tool off until configs allows it. One server is shared, yet each application gets only the tools its role needs.

response = client.beta.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=2048,
    betas=["mcp-client-2025-11-20"],
    mcp_servers=[{
        "type": "url",
        "url": "https://stockledger-mcp.example.com/mcp",  # remote server, https only
        "name": "stockledger",
        "authorization_token": token,  # your app runs the OAuth flow and refreshes it
    }],
    tools=[{
        "type": "mcp_toolset",
        "mcp_server_name": "stockledger",
        "default_config": {"enabled": False},  # allowlist: every tool off by default
        "configs": {"get_stock_level": {"enabled": True},
                    "get_inbound_shipments": {"enabled": True}},
    }],
    messages=[{"role": "user", "content": question}],
)

3.7.3 Direct API integration: a custom tool in your own code

Now the price-proposal store. No other AI application writes there, and none is planned. An MCP server in front of it would add a service to deploy, secure, version and monitor, for exactly one client.

The simpler mechanism is a custom tool, which the docs call a user-defined, client-executed tool. You write its name, description and input schema in your application. Claude decides when to request save_price_proposal and with what inputs; your code runs the call against your own service and returns the result. Claude never sees your implementation, only the schema and the result.

That ownership is the point. Everything an auditor asks about sits in one codebase: the cost-floor check on every markdown, the idempotency key that stops a double save, the log line that records who approved what. The price is reuse. If a second AI application wants proposals next year, it must build the integration again, and by then MCP has become the better answer.

Memorise the last row; it settles most choices between these two.

3.7.4 CLI: let an agent in a shell use the tools you already have

The third connection belongs to the assistant's engineers. The rollout and lakeq tools already exist, sign each engineer in with their own single sign-on (SSO) account, log every command per user and document themselves through --help. The engineers work in Claude Code, Anthropic's agentic coding tool, which can run shell commands. So the cheapest integration is no new integration: Claude Code runs the CLIs through its shell, as an engineer would.

Anthropic's Claude Code guidance recommends exactly this: use CLI tools such as gh, aws or gcloud with external services, because CLI tools are the most context-efficient way to reach them. No schema sits in the context window, and Claude can read a tool's --help to learn one it has never seen. It is like hiring a contractor who already knows the tools in your workshop.

The costs are identity and place. The agent acts with whatever credentials the shell holds, so an engineer's own scoped login is fine and a shared admin token in a config file is not. Claude Code's permission rules, which Claude Code enforces whatever the model decides, can let lakeq queries run freely and make every rollout command ask first. When many teams need governed access to sensitive systems and security wants no tokens on laptops, a central MCP server is the better control point.

In Anneliese's review, someone suggested that the production assistant shell out to lakeq for sales history. She declined for the reasons in the diagram: data needed at run time is an MCP or direct-tool question. The same rule covers how a production service reaches Claude itself. It calls the Messages API through an SDK, with its own API key, telemetry and scaling, rather than spawning Claude Code from the command line for every request.

3.7.5 Agent-to-agent: delegating to an agent you do not own

Veltaro is different in kind. Its pricing agent plans and runs its own models over its own competitor and demand data. A large range can take an hour, and the agent sometimes asks a question back, such as the margin floor for a category. Veltaro will not expose its tools or data, and Thistlecombe has no wish to rebuild Veltaro's expertise. The assistant needs to hand over a goal and get a result back, the way you brief a consultancy and receive its report while its working notes stay its own.

That is agent-to-agent delegation, and A2A is the open standard for it, originally developed by Google and now under the Linux Foundation. The remote agent publishes an Agent Card, a JSON document giving its identity, endpoint, skills and authentication requirements. For work that takes time, the agent answers with a Task that has an ID and a lifecycle. Its states include working, input-required, completed and failed (in the protocol, values such as TASK_STATE_INPUT_REQUIRED). Results arrive as Artifacts, and the client follows progress by polling, by a stream of server-sent events or by push notifications.

The property that matters most is opacity. The remote agent's memory, tools and reasoning stay private, which protects the vendor and bounds your audit: you can log what you sent, every state change and what came back, but not how Veltaro decided. A2A runs over HTTPS with authentication declared in the Agent Card, so both sides can pass trace context in standard HTTP headers and join ordinary distributed tracing. An hour-long run also cannot hold a merchandiser's chat open: the assistant starts the task, says the plan is coming and collects the Artifact on completion.

A2A complements MCP rather than replacing it. Its documentation calls MCP vertical, connecting one agent to its own tools and data, and A2A horizontal, connecting agents across a team or company boundary; Veltaro's agent may well use MCP inside. On Thistlecombe's side, Claude decides that it needs a price recommendation, and the application, acting as the A2A client, sends the task and tracks it. A2A is not a sub-agent protocol either: agents inside one system use their framework's own sub-agents.

3.7.6 Choosing: six questions that decide the mechanism

Every choice so far came down to six requirements.

1. OWNERSHIP. Who owns each side: you, a shared internal team, another company?
2. CLIENTS. How many AI applications or agents need it, now and on the roadmap?
3. AUTH. Whose identity does each call carry, and where do the credentials live?
4. STATE. A quick request and response, or a long, multi-turn task that can pause for input?
5. LATENCY. Is a person waiting on a request path, or is this background work?
6. GOVERNANCE. Where do you enforce scope and keep the audit trail, and what can you see beyond it?

Memorise the "when it wins" column; the costs column is where distractors hide their flaw. Anneliese closes the review with a decision record, one line per connection, each naming the requirement that decided it.

DECISION 014: Integration mechanism per connection, merchandising assistant, Thistlecombe Retail Group.
StockLedger inventory: MCP. Four AI applications need it (CLIENTS); remote server owned by the inventory team, OAuth on the server, one audit log; each application allowlists only the read tools it needs.
Price-proposal store: direct custom tool. Only this assistant writes to it (OWNERSHIP); cost-floor checks and idempotency live in our code. Revisit if a second application needs it.
Veltaro pricing agent: A2A. Vendor-owned and opaque, runs up to an hour, may ask for margin floors (STATE); results reach the merchandiser asynchronously; we log task IDs, state changes and artifacts.
rollout and lakeq: CLI through Claude Code, engineers only. Per-user SSO and audit already exist (AUTH); lakeq queries allowed, rollout always asks. Not on the production request path.
Rejected: one mechanism for every connection; the production assistant shelling out to lakeq.

3.7.7 The exam traps

Every trap here applies a good mechanism to the wrong shape of connection.

• ✗ Standardising on MCP for every connection because it is the standard. ✓ Use MCP where several AI applications or agents share a capability. One application calling its own service is a direct custom tool: the smallest surface, nothing extra to run.
• ✗ Letting every AI application build its own connector to the same system. ✓ Publish the capability once as an MCP server, with one set of schemas, one auth model and one audit log that every client reuses.
• ✗ Putting a CLI on a production request path, such as a service that spawns a command for every user request. ✓ Services call the Messages API or a proper service interface; CLIs belong to agents working in a shell beside a person, with scoped credentials and permission rules.
• ✗ Asking an outside vendor to expose its internal tools and data so your own agent can do the vendor's job. ✓ Delegate the goal over A2A and let the vendor's agent keep its tools and reasoning private; the task lifecycle carries long runs and questions back.
• ✗ Reaching for agent-to-agent where a function call would do. ✓ If the other side has fixed inputs and outputs, call it as a tool; A2A earns its cost only when you delegate a goal to an autonomous agent. Inside one system, use sub-agents, not A2A.

3.7.8 Put it together: choose and justify each connection

You now have the four mechanisms, their costs and the six requirements that decide between them. To make them stick, build one capability three ways, watch the MCP connector refuse a server it cannot reach, and write the decision down.

Progressive discovery (3.8) keeps hundreds of MCP tools within reach without loading every definition up front. Communicating architectural decisions (6.2) turns a decision record like Anneliese's into a case stakeholders accept, and configuring Claude tools for teams (7.1) rolls out the shared MCP servers and CLI permission rules chosen here.

Key takeaways

• ✓ Choose the integration per connection, by who owns each side, how many AI applications need it, and whether the other side is a function or an agent.
• ✓ MCP publishes tools, resources and prompts once as a server any MCP host can use; it wins when several AI applications or agents share a capability.
• ✓ The Claude API's MCP connector reaches remote HTTPS servers for tool calls only; local servers, resources and prompts need your own MCP client.
• ✓ A direct custom tool gives one application the tightest control and the smallest new surface, at the price of reuse.
• ✓ A CLI lets an agent in a shell reuse existing tools, auth and documentation with little context overhead; keep it off production request paths and scope its credentials.
• ✓ A2A delegates a goal to another party's opaque agent through Agent Cards, stateful Tasks and Artifacts; it complements MCP and is not a sub-agent protocol.
• ✓ Justify every choice by naming the requirement that decided it: ownership, clients, auth, state, latency or governance.

Check your understanding

4 questions written for this lesson, then one from the CCAR-P question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• MCP architecture overview
• MCP connector
• How tool use works
• Best practices for Claude Code
• A2A protocol
• A2A specification
• A2A and MCP
• The CCAR-P exam guide, summarised