10.3 MCP Architecture & Core Primitives

MCP Architecture & Core Primitives

Exam Blueprint Focus: The Model Context Protocol (MCP) represents Anthropic's open standard for connecting AI models to external tools, databases, and contextual data. The CCDV-F exam requires deep architectural understanding of why MCP was created, its underlying JSON-RPC 2.0 messaging protocol, the three core primitives (Tools, Resources, Prompts), capability negotiation during initialization, and the operational boundaries between MCP Hosts, Clients, and Servers.

---

The Integration Challenge & The Model Context Protocol

Prior to the introduction of MCP, enterprise AI developers faced an unsustainable $M \times N$ integration crisis:

• There are $M$ different AI models, runtime environments, and developer frontends (Claude Desktop, Claude Code, custom internal agents, IDE extensions, web chat interfaces).
• There are $N$ different enterprise data sources, development tools, and business APIs (PostgreSQL databases, GitHub repositories, Slack workspaces, Jira trackers, local file systems, internal REST services).

Without a universal standard, connecting every host to every data source required writing $M \times N$ bespoke, proprietary adapters. Each adapter had its own error handling, authentication scheme, schema definition, and security model. Maintenance costs scaled quadratically, and adding a new tool required rewriting code across every application.

THE FRAGMENTED M x N CRISIS:             THE STANDARDIZED MCP ARCHITECTURE:

[ Claude Desktop ]   [ Custom Agent ]     [ Claude Desktop ]   [ Custom Agent ]
    \     /              \     /               \                  /
     \   /                \   /                 \                /
    [ Bespoke ]      [ Custom Glue ]            v                v
    [ Plugins ]      [ Code / REST ]       +--------------------------+
      /    \            /    \             |       MCP CLIENT         |
     /      \          /      \            +--------------------------+
[ Postgres ] [ GitHub ] [ Slack ]                      |  (JSON-RPC 2.0)
                                                       v
                                           +--------------------------+
                                           |       MCP SERVERS        |
                                           | [Postgres] [GitHub] [FS] |
                                           +--------------------------+

In late 2024, Anthropic open-sourced the Model Context Protocol (MCP) to establish the "USB-C of AI connectivity." MCP is an open, vendor-neutral standard that standardizes how AI applications communicate with local and remote data stores and tools. By adopting MCP, developers write a single server for a data source (e.g., an MCP Postgres Server), and that server becomes immediately accessible to any MCP-compliant host application.

---

Protocol Foundation: JSON-RPC 2.0 Specification

MCP is built on top of the JSON-RPC 2.0 specification. JSON-RPC 2.0 provides a lightweight, stateless, language-agnostic, and transport-independent mechanism for executing remote procedure calls over bidirectional channels.

Message Types in MCP

MCP utilizes three standard JSON-RPC 2.0 message formats:

1. Requests: Messages sent from client to server (or server to client) expecting a response. Must include a unique id:

   {
     "jsonrpc": "2.0",
     "id": 101,
     "method": "tools/call",
     "params": {
       "name": "query_database",
       "arguments": {"sql": "SELECT * FROM users LIMIT 5"}
     }
   }
   

2. Responses: Sent in reply to a request with a matching id. Contains either a result object or an error object:

   {
     "jsonrpc": "2.0",
     "id": 101,
     "result": {
       "content": [{"type": "text", "text": "[{\"id\": 1, \"name\": \"Alice\"}]"}]
     }
   }
   

3. Notifications: One-way messages that do not include an id. Notifications never receive a response and are used for event broadcasting, progress updates, and resource invalidation:

   {
     "jsonrpc": "2.0",
     "method": "notifications/resources/updated",
     "params": {
       "uri": "file:///workspace/project/schema.sql"
     }
   }
   

The Initialization Handshake & Capability Negotiation

Before any tools, resources, or prompts can be exchanged, the MCP Client and MCP Server must perform a strict capability negotiation handshake:

1. initialize Request: The client sends an initialize request declaring its protocol version, client metadata, and supported capabilities (e.g., roots, sampling).
2. initialize Response: The server responds with its protocol version, server metadata, and declared capabilities (e.g., tools: {listChanged: true}, resources: {subscribe: true}, prompts: {listChanged: true}).
3. notifications/initialized Notification: The client sends an unacknowledged notification confirming the handshake is complete. Only after this notification is sent can standard RPC calls proceed.

---

The Three Core MCP Primitives

MCP structures all context and functionality into three foundational primitives, each calibrated for a distinct operational role and control plane:

1. Tools: Model-Controlled Actions

• Definition: Executable functions that allow Claude to perform computations, trigger business logic, or mutate external systems.
• Control Plane: Model-controlled. Claude determines autonomously whether and when to invoke tools based on user instructions and registered schemas.
• Side Effects: Tools are explicitly permitted and expected to have side effects (e.g., writing records to a database, deploying a container, sending a Slack message).
• Protocol Methods:
  • tools/list: Discovers available tools and their JSON Schema parameter definitions.
  • tools/call: Executes a tool with specific arguments.
  • notifications/tools/list_changed: Server notifies client that tools were added or updated.

2. Resources: Application-Controlled Contextual Data

• Definition: Read-only data sources that provide passive background context, ground-truth data, or system state to the AI model.
• Control Plane: Application-controlled. The host application or end user decides which resources to read and attach into the model's prompt. The model does not autonomously fetch resources without host orchestration.
• Addressing Scheme: Resources are addressed via standardized URIs (Uniform Resource Identifiers), such as file:///workspace/src/index.ts, postgres://cluster/prod/orders/schema, or github://repos/org/repo/issues/42.
• Side Effects: Strictly read-only and idempotent. Reading a resource must never alter system state.
• Content Payloads: Can return UTF-8 text or base64-encoded blob data (for binary assets like PDFs, images, or audio).
• Dynamic Templates & Subscriptions: Servers can expose dynamic URI patterns via resources/templates/list (e.g., git://repo/{branch}/commit/{hash}) and clients can subscribe to real-time changes via resources/subscribe.

3. Prompts: User-Controlled Interactive Workflows

• Definition: Pre-configured prompt templates, slash commands, and guided multi-turn interaction patterns exposed by the server.
• Control Plane: User-controlled. Prompts are surfaced in the client UI for the end user to select (such as typing /code-review or /generate-api-client in Claude Desktop).
• Arguments & Messages: Prompts accept user arguments and return a structured array of prompt messages (role: "user" or role: "assistant") pre-populated with context and resource references.
• Protocol Methods:
  • prompts/list: Discovers available prompt templates and required argument schemas.
  • prompts/get: Renders the specified prompt with user-supplied arguments.
  • notifications/prompts/list_changed: Server notifies client of template updates.

---

Comprehensive Comparison: Tools vs Resources vs Prompts

---

Client-Server Architectural Topology

MCP establishes a strict separation of concerns across three distinct entities:

+-------------------------------------------------------------------------+
|                                MCP HOST                                 |
|  (Claude Desktop, Claude Code CLI, Custom Agent Runtime, IDE Extension)  |
|                                                                         |
|  - Orchestrates conversation turns and user interface                   |
|  - Manages LLM inference (Anthropic Messages API calls)                 |
|  - Enforces user security policies & confirmation prompts                |
|                                                                         |
|    +---------------------------------------------------------------+    |
|    |                          MCP CLIENT                           |    |
|    |  - Manages 1:1 connection to an MCP Server                   |    |
|    |  - Handles JSON-RPC 2.0 serialization/deserialization         |    |
|    |  - Routes requests and receives event notifications           |    |
|    +---------------+-------------------------------+---------------+    |
+--------------------|-------------------------------|--------------------+
                     | (Transport: Stdio)            | (Transport: Streamable HTTP)
                     v                               v
       +--------------------------+    +--------------------------+
       |     LOCAL MCP SERVER     |    |    REMOTE MCP SERVER     |
       | (Filesystem, Local Git)  |    | (Postgres Cloud, Slack)  |
       +--------------------------+    +--------------------------+

1. MCP Host: The outer user-facing application (e.g., Claude Desktop, Cursor, Claude Code, or an enterprise agent platform). The host coordinates the overall workflow, presents the UI, stores conversation history, holds API keys for the LLM, and prompts human users for confirmation before executing state-mutating actions.
2. MCP Client: The protocol adapter maintained by the host. A host instantiates one MCP Client per connected MCP Server. The client maintains protocol state, executes initialization handshakes, serializes JSON-RPC messages, and dispatches requests.
3. MCP Server: A lightweight, decoupled service that exposes specific capabilities. A server specializes in a single domain (e.g., a GitHub MCP Server exposes GitHub repositories and issue tools). MCP Servers have no direct relationship with the LLM; they simply respond to JSON-RPC requests from the MCP Client.

---

Security Boundaries & Permission Models

Because MCP Tools can perform arbitrary operations (including deleting files, altering databases, or transferring funds), MCP enforces strict security boundaries:

• Human-in-the-Loop Verification: MCP hosts must implement confirmation prompts for sensitive tools. When Claude emits a tools/call for a destructive tool, the host pauses execution and presents the exact arguments to the human user for approval.
• Root Scoping: For filesystem servers, hosts can declare authorized filesystem "roots" during initialization, restricting the server from traversing outside assigned directories.
• Sampling: MCP supports a protocol capability called Sampling (sampling/createMessage), whereby an MCP Server can request the Host to perform an LLM completion on its behalf. This allows servers to leverage AI reasoning while ensuring that token billing, model selection, and safety guardrails remain strictly under the Host's control.

---

Exam Watchouts & Common Anti-Patterns

1. Conflating Tools and Resources: Remember that Resources are passive and read-only; Tools are active and can produce side effects. Passing a database update function as a Resource violates MCP architecture.
2. Assuming MCP Servers Call Claude: MCP Servers do not call the Anthropic API to generate completions for the user. The Host calls the Anthropic API; the server merely executes local RPC requests.
3. Missing notifications/initialized: In custom MCP client implementations, failing to send the unacknowledged notifications/initialized notification leaves the server in an uninitialized state, causing subsequent requests to be rejected.