# MCP vs Direct API Integration

MCP is a reusable standard layer for exposing tools/data to any MCP host; a direct API call is bespoke, app-specific glue.

## Why the CCAR-P exam tests this

P3 asks you to justify an integration choice, and the trade-off between standardization and simplicity is a favorite discriminator.

## Definition

**MCP** wraps a capability once as a server that any MCP-compatible host can consume — tools/resources/prompts, standard discovery, standard auth. It shines when the same capability serves **many hosts/agents**, when you want **dynamic discovery** of available tools, or want to reuse the growing MCP ecosystem. Cost: you run and secure a server and adopt the protocol.

A **direct API integration** hardcodes a specific call inside your app — the shortest path for a **single, stable, one-off** dependency where you fully control both ends and need no discovery or reuse. Cost: it doesn't compose, and every new consumer re-implements the glue.

Security posture differs in shape, not principle. Either way, use **delegated per-user OAuth tokens**, **least privilege**, and never embed shared static secrets in something the model can reach. MCP additionally standardizes that auth handshake for remote servers, which is part of its value when many clients connect.

## Exam trap

'Always use MCP' and 'always call the API directly' are both wrong — the answer is driven by reuse, number of consumers, and need for dynamic tool discovery, not a blanket rule.

## Commonly confused with

- **mcp** — This term is the decision/trade-off; 'mcp' is the protocol's architecture and primitives.
- **data-layer-acls** — Both integration styles still owe you data-layer authorization; the choice of layer doesn't change that duty.

## Related

- mcp
- data-layer-acls
- observability-tracing

---

Source: Claude Cert Prep — an independent, unofficial CCAR-P study resource (domain P3). Not affiliated with Anthropic.