MCP Architecture

The Model Context Protocol (MCP) architecture is designed to create a standardized, scalable way for AI “Hosts” (like chatbots) to interact with various “Servers” (tools and data sources).

The following documentation breaks down the architecture from its core entities to its technical layers, including a structural diagram representing the “working” system.

---

1. The Core Entities of MCP #

The MCP architecture is built on three fundamental pillars that interact to facilitate communication between an AI and external tools.

A. The Host (The AI Application)

The Host is the AI chatbot or interface that the user interacts with (e.g., Claude Desktop or a custom-built chatbot). It is connected to a Large Language Model (LLM) like GPT-4 or Gemini. When a user asks a question that requires external data, the Host realizes it needs a tool or server to find the answer.

B. The MCP Client (The Connector)

Crucially, a Host never speaks directly to a Server. It uses an MCP Client as a helper. The Client’s primary role is to translate high-level requests from the Host into the specific “MCP language” (JSON-RPC) that the server understands.

C. The MCP Server (The Tool)

A Server is a specialized entity with the capability to execute specific tasks, such as managing a GitHub repository, reading Google Drive files, or accessing a Slack channel

---

2. Working Architecture Diagram #

Based on the “final architecture” described in the sources, the system functions as follows:

3. The Relationship Model: One-on-One Scalability #

MCP follows a strict one-on-one relationship between a Client and a Server.

• One Client per Server: If a Host needs to connect to three different servers (e.g., GitHub, Slack, and Drive), it must use three separate clients.
• Decoupling: This architecture ensures a separation of concern. If the GitHub connection fails, the Slack and Drive connections remain unaffected, ensuring system safety.
• Parallelism: Because each communication line is independent, a Host can perform tasks across different servers parallelly, making execution faster.

---

4. Server Primitives (Offerings) #

Every MCP Server provides three types of offerings, known as primitives, which define what the AI can actually do with that server.

Primitive	Description	Example
Tools	Dynamic actions the AI can perform.	Creating a GitHub issue or searching for a file in Drive.
Resources	Structured, static data sources the AI can read.	Fetching a README.md file or a database schema.
Prompts	Pre-defined templates to shape the AI’s behavior.	A template ensuring the AI generates a detailed, structured bug report.

MCP also provides Standard Operations (e.g., list, call, read, subscribe) to interact with these primitives in a uniform way.

---

5. The Data Layer: JSON-RPC 2.0 #

The “language” spoken by the MCP ecosystem is based on JSON-RPC 2.0. This protocol allows the AI to call a function on a remote machine as if it were a local function, hiding the complex details of network communication.

Why JSON-RPC instead of REST APIs?

MCP uses JSON-RPC for several technical advantages:

• Lightweight: It lacks the heavy headers and metadata required by REST, making messages simpler to write, debug, and transport.
• Bi-directional: Unlike the one-way communication of REST, JSON-RPC allows both the Client and Server to send requests to each other.
• Batching: It supports sending multiple requests (e.g., listing both issues and pull requests) in a single message.
• Notifications: It allows for “fire-and-forget” notifications where a response is not required, which is useful for real-time updates.

---

6. The Transport Layer: STDIO vs. HTTP/SSE #

The transport layer is the mechanism that physically moves the JSON-RPC messages. The mode of transport depends on whether the server is local or remote.

A. Local Servers (STDIO) #

When a server is installed on the same machine as the Host, it is a Local Server.

• Mechanism: The Host launches the server as a sub-process, establishing a parent-child relationship. This gives the Host control over the server’s Standard Input/Output (STDIO) streams.
• Process: The Client sends a JSON-RPC message into the server’s input stream; the server processes it and sends the result back through its output stream.
• Benefits: This is extremely fast, highly secure (no network ports are opened), and simple to implement.

B. Remote Servers (HTTP + SSE) #

When a server is on the internet, it is a Remote Server.

• HTTP POST: The Host sends JSON-RPC messages as payloads within standard HTTP POST requests.
• SSE (Server-Sent Events): This extension of HTTP allows the server to stream incremental updates back to the client. This is ideal for long-running tasks or providing a “streaming” AI response experience.

---

7. Strategic Brilliance: Transport Agnosticism #

A key feature of MCP is that the Data Layer is decoupled from the Transport Layer. Because JSON-RPC is transport-agnostic, the way messages are written remains identical regardless of whether they are being sent via STDIO locally or HTTP/SSE remotely. This design makes MCP incredibly flexible and future-proof

MCP Architecture Quiz #