Claude Certified Engineers logoCCE

CCAR-P · Study Guide

← Domain 3: Integration

3.7 · Lesson 7 of 8

Evaluate connection protocols and select the appropriate integration mechanism (MCP, API/CLI, agent-to-agent)

What You Need to Know

Connection protocols are how Claude systems reach the outside world. MCP provides a shared tool and resource surface across hosts and clients. Direct API or CLI integrations suit owned, narrow paths where a shared server adds little. Agent-to-agent connections keep roles isolated with explicit handoffs when specialists must not share one mega-toolkit.

Architects choose the mechanism from reuse, ownership, and control needs — not from habit. Secrets stay in secure configuration. Resources expose catalogues; tools expose actions. Mixing these concerns leads to brittle curl-in-prompt patterns that fail both exams and audits.

Decision rules

  • High reuse + shared tools/resources → MCP (or equivalent shared server).
  • Owned, narrow, single-consumer path → API/CLI is often enough.
  • Role isolation and separate contexts → agent-to-agent with explicit handoffs.
  • Never treat secrets-in-prompts as an integration strategy.
  • Revisit the choice when a second consumer or new blast-radius requirement appears.

Decision table (exam mental model)

  • Many clients, shared tools/resources, clear hosts → MCP (or equivalent shared server)
  • Single owned consumer, narrow API, little reuse → API/CLI client
  • Specialists needing isolation and separate contexts → agent-to-agent handoffs
  • Secrets in prompts / CSV email loops → never an architecture answer

Tools vs resources vs agents

Tools are actions. Resources are catalogues the host can attach. Agents are reasoning roles. Confusing these leads to peer agents pretending to be a shared database, or MCP servers that duplicate a one-off curl. Good designs often combine mechanisms: MCP for the shared catalog, API for a batch job, agent-to-agent for a compliance reviewer with a tight tool scope.

Revisit the choice when a second consumer appears — yesterday's CLI can become tomorrow's MCP surface.

Exam application

Protocol follows reuse and boundaries. Shared tools/resources → MCP; owned narrow path → API/CLI; role isolation → agent-to-agent. Distractors: secrets in prompts, always-MCP, or peer meshes as a fake shared catalog.

Exam traps

  • Always choosing MCP

    Narrow, owned integrations with no reuse may be simpler as direct API/CLI. Protocol follows need.

  • Always choosing raw API/CLI

    When many clients need the same tools/resources, a shared server reduces drift and duplication.

  • Using agent-to-agent as a substitute for tools

    Peer agents isolate roles; they do not replace a stable tool/resource contract for shared systems.

  • Putting secrets in prompts as "integration"

    Credentials belong in secure config and env expansion — never in model text.

Practice scenario

Several internal products need the same set of tools and read-only resources (schema catalogs, runbooks) with clear host/client boundaries and reuse across teams. A one-off curl wrapper inside a single agent would not be shared. Which integration mechanism fits best?

Choose one answer

Build exercise

Pick protocols for a multi-product internal platform

35 minutes

What you'll learn

  • Score reuse, ownership, and isolation
  • Stand up a shared MCP surface when reuse is real
  • Keep API/CLI for narrow owned paths
  • Use agent-to-agent for role isolation

  1. Step 1

    Score the integration on reuse, ownership, and control

    Ask: How many clients? Who owns the connector? Do you need resources as well as tools? Must roles stay isolated?

    Why: Protocol choice is a decision table, not a default brand.

    You should see: A short scorecard with recommended mechanism and rejected alternatives.

  2. Step 2

    Prototype the shared surface only when reuse is real

    If two or more products need the same tools, define an MCP server (or internal equivalent) with tool schemas and optional resources for catalogs.

    Why: Premature shared servers add ops cost; missing shared servers create curl drift.

    You should see: A server exposing ≥1 tool and ≥1 resource consumed by two different hosts in a dry run.

  3. Step 3

    Prefer API/CLI for single-owner, low-reuse paths

    Document when a direct SDK or CLI is enough — e.g., one batch job calling an internal API with no other consumers.

    Why: Exam items reward matching mechanism to ownership and reuse, not maximal architecture.

    You should see: An ADR that picks CLI for the batch path and MCP for the multi-product path.

  4. Step 4

    Use agent-to-agent when isolation is the requirement

    Keep specialist agents with separate tool scopes and explicit handoffs when roles must not share a mega-toolkit.

    Why: Protocol and multi-agent design interact: isolation is not the same as shared tool hosting.

    You should see: A coordinator invoking a specialist with an explicit context packet — not a shared god-tool list.

Sources