MCP Explained on One Diagram: The USB-C Port for AI Tools

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 2)

▶ Watch on YouTube & subscribe to The Stack Underflow

Every time you give an AI model a new tool, somebody writes a new adapter — a new API, a new schema, new glue code. Do that across three models and four tools and you have twelve bespoke integrations, each one slightly different, each one a maintenance liability. That is the N-times-M problem, and it is the reason the Model Context Protocol (MCP) exists. The comparison everyone reaches for — “USB-C for AI” — is not just marketing. It is structurally accurate: one standard port, and any tool plugs into any model that speaks the protocol.

The one-sentence version: MCP standardizes the interface between a model-driven application and a tool, not the tools themselves — so you write the adapter once, and every MCP-speaking model can use it.

The problem MCP solves

Before a shared protocol, every pairing of model and tool needed its own integration. Three models times four tools is twelve pieces of glue code — each with its own auth handling, its own request shape, its own error format.

BEFORE MCP — N models × M tools = bespoke glue everywhere

  MODEL A ───adapter───┐
  MODEL A ───adapter───┼──► SEARCH TOOL
  MODEL B ───adapter───┤
  MODEL B ───adapter───┼──► WRITE TOOL
  MODEL C ───adapter───┤
  MODEL C ───adapter───┴──► QUERY TOOL

  12 pairings, 12 different adapters, 12 things that can silently drift.

AFTER MCP — one standard interface in the middle

  MODEL A ─┐
  MODEL B ─┼──►  [ MCP ]  ──► SEARCH · WRITE · QUERY
  MODEL C ─┘      one port        (each behind an MCP server)

  Any MCP-speaking model can call any MCP-exposed tool. No pairwise glue.

Nothing about the tools changed. What changed is that the interface between “thing that decides to act” and “thing that acts” is now one protocol instead of N×M protocols. That distinction — standardize the interface, not the tool count — is the single idea to hold onto for the exam and for real system design.

The three roles

MCP defines three participants, and mixing up their responsibilities is the most common source of confused answers on practice questions:

The client is not the model — it is the surrounding application (Claude Code, for instance) that manages the conversation and decides which MCP servers are available. The server does not do the work itself; it translates MCP calls into whatever the underlying system actually needs (a REST call, a SQL query, a file read). The model never talks to the tool directly — it always goes through the server, over the protocol.

The round-trip

Once a client is connected to a server, using a tool follows the same four-step exchange every time:

CLIENT                                          SERVER
  │                                                │
  │  1. "list tools"  ─────────────────────────►   │
  │  ◄───────────────  "tools: [search, write,     │
  │                      query]"  2.                │
  │                                                │
  │  (model reads the descriptions, picks one)      │
  │                                                │
  │  3. "call search(q='pricing docs')" ─────────►  │
  │  ◄───────────────  "result: [...]"  4.          │
  │                                                │
  │  result is inserted back into the model's       │
  │  context as an observation                      │

Steps 1–2 are discovery — the client asks the server what it can do, and the server returns tool names, descriptions, and parameter schemas. Step 3 is the call — the model, having seen those descriptions, decides to invoke one with specific arguments. Step 4 is the result — the server’s response comes back and is written into the model’s context, closing the loop. This is the same observe-act-observe pattern that runs the broader agent loop — MCP is simply the standardized wire format for the “act” half of that loop.

What a server can expose

An MCP server is not limited to callable actions. The spec defines three primitive types:

Most exam questions and most real usage revolve around tools, but resources and prompts exist for good reason: not everything a server offers should require a model decision to “call” it. A resource is closer to RAG-style context injection than to an action.

Transport: same protocol, different wire

MCP separates what gets said from how it travels. Two transports cover the common cases:

• stdio — the server runs as a local subprocess, and the client talks to it over standard input/output. This is the default for local tools: a filesystem server, a local dev-database server.
• Streamable HTTP (with optional SSE for streaming) — the server runs as a remote service, and the client talks to it over HTTP. This is what you use for shared, team-facing, or SaaS-hosted servers.

Same protocol either way — the messages, the discovery step, the call/result shape are identical. Only the wire changes. When a question asks “should this MCP server run locally or remotely,” it is really asking whether the capability is single-machine (stdio) or needs to be reachable by multiple clients/teams (HTTP).

MCP vs inline functions vs RAG

This is the decision an architect actually needs to make repeatedly, and it is the “money frame” of the whole topic:

              Does this capability get reused
              across tools, teams, or sessions?
                          │
              ┌───────────┴───────────┐
             YES                      NO
              │                        │
        MCP SERVER              INLINE FUNCTION CALL
   (standard interface,        (define it directly in
    discoverable, shared)       this one agent's tool list)

        Side question: does the agent need KNOWLEDGE,
        not an ACTION? → that's RAG, not MCP.

That last row matters: MCP and RAG are not competing answers on the exam. MCP grants what an agent can DO; RAG fills what it KNOWS. A support agent might use RAG to retrieve the relevant policy document and an MCP server to actually issue the refund — same turn, two different mechanisms. See RAG vs MCP: Which Is Which, and When to Use Each for the full breakdown of that boundary.

When NOT to use MCP

MCP is not free. Standing up a server means an extra process (or deployment), an auth story, and the token cost of tool discovery and results flowing through context. For a single function that one agent calls, that overhead buys you nothing — inline function-calling is simpler, faster to ship, and has one less moving part to secure and monitor. Reach for MCP when the coordination problem it solves (many models, many tools, need to standardize) is real. If it’s one model and one tool, skip it.

The Claude Code angle

Claude Code itself is an MCP host — the client role in the diagram above. When you add an MCP server to Claude Code’s settings, its tools become available to the agent alongside Claude Code’s built-in tools, with no changes to Claude Code itself required. This is the mechanism by which Claude Code (and similar coding agents) get extended with project-specific or team-specific capabilities — a database server, an internal ticketing system, a design tool — without anyone touching the host application’s source. On the exam this shows up as a Domain 2 favorite: “a team wants to add capability X to their coding agent — what’s the right mechanism?” The answer is almost always: write or install an MCP server, don’t fork the agent.

Exam context

MCP is the single heaviest concept spanning two domains of the Claude Certified Architect exam: it’s core to Domain 2 (Tool Design & MCP Integration), and it threads through Domain 1 (Agentic Architecture & Orchestration) since the round-trip above is the “act” phase of the agent loop. As of mid-2026 the exam runs through Pearson VUE, costs $125 with retakes available, is 60 questions in 120 minutes, and requires a scaled score of 720/1000 to pass across five domains — verify current logistics on Anthropic’s official pages before you register, since fees and formats can change. The full domain breakdown is in the CCA Exam Guide.

Frequently asked questions

Is MCP an Anthropic-only protocol? No. MCP is an open protocol, and its adoption extends beyond Claude — but on the Claude Certified Architect exam, expect it framed through Claude Code and the Claude API as the host/client side.

Does MCP replace function calling? Not conceptually — MCP is a standardized way to do tool/function calling, plus discovery and a shared wire format. Inline function calling still has a place for one-off, non-reused tools; MCP is what you reach for when that tool needs to be discoverable and reusable across more than one consumer.

Can one MCP server expose both tools and resources? Yes. A single server commonly exposes a mix of tools (actions), resources (readable data), and prompts (templates) — there’s no rule limiting a server to one primitive type.

Why “USB-C for AI” and not something more precise? Because the analogy captures the actual value proposition in one image: a single standardized physical/logical interface that lets many devices (models) plug into many peripherals (tools) without pairwise adapters. It’s an analogy, not a literal hardware standard — say so if you use it in an explanation, since the exam rewards precision over vibes.

What’s the difference between an MCP server and an MCP host? The host is the application driving the conversation with the model (Claude Code, Claude Desktop, a custom agent) — it initiates connections to servers and passes their tool descriptions to the model. The server is the thing being connected to — it wraps a real capability. A host can connect to many servers at once; a server doesn’t know or care which host is calling it.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Where this fits in the series

This explainer sits at the front of the Claude Certified Architect (CCA) Exam Guide — MCP is the plumbing that every Domain 1 and Domain 2 practice question assumes you already understand. Once the round-trip in this diagram is second nature, the companion explainer on RAG vs Context Engineering covers the other half of the “DO vs KNOW” split: what an agent knows, versus what it can act on. Browse all tutorials for the rest of the series.