MCP Protocol Architecture Deep Dive: Host-Client-Server Three-Layer Design and Three Core Primitives

In AI Agent development, the fragmentation of tool integration has always been an unavoidable pain point. Every time you connect a new tool, you need to write a set of adapter code; every time you switch models, you have to redo the adaptation logic from scratch. The MCP (Model Context Protocol) proposed by Anthropic is fundamentally changing this landscape. This article provides an in-depth breakdown of MCP's architecture design and core concepts, helping you understand how it transforms the chaotic M×N integration approach into a standardized M+N industrial-grade solution.

The Fragmentation Nightmare: Why Traditional M×N Integration Doesn't Scale

Before MCP, the state of AI tool integration was much like the early days of phone chargers—Apple had its own connector, Android had its own, and even different Android brands weren't compatible with each other.

In the Agent space, this problem is amplified exponentially. Suppose you have 10 models that need to switch between different platforms, along with 50 tools (GitHub, databases, search engines, etc.). Under the traditional approach, you'd need to write specialized adapter code for every model targeting every tool. That means maintaining 10×50=500 sets of glue code.

Developers spend all their time writing repetitive, low-value adapter code instead of focusing on actual business logic. This is the so-called M×N fragmentation nightmare—integration costs grow with the product of the number of models and tools, making it fundamentally unscalable.

Background: How LSP Inspired MCP's Design

This dilemma is not unique to AI. The Language Server Protocol (LSP) was proposed by Microsoft in 2016 to solve the exact same M×N integration problem between IDEs and programming language toolchains—every editor needed separate implementations of code completion, go-to-definition, error checking, and other features for each language. By defining a standardized communication protocol, LSP allows language tools to implement a Language Server just once, making it usable by all LSP-supporting editors. Today, virtually all mainstream IDEs support LSP, spawning hundreds of high-quality Language Servers. MCP's designers clearly drew inspiration from LSP's success, attempting to replicate this standardization dividend in the AI tool ecosystem—which is why MCP is sometimes called "the LSP for AI tools."

MCP's Core Logic: From M×N to M+N Standardized Bus Architecture

MCP's core logic can be summarized in one word—standardization. It transforms the previously chaotic point-to-point wiring into a unified bus architecture.

MCP (Model Context Protocol) was officially open-sourced by Anthropic in November 2024, born from extensive engineering practices accumulated during the construction of the Claude ecosystem. At its technical foundation, MCP is an application-layer protocol based on JSON-RPC 2.0. The choice of JSON-RPC over REST or GraphQL was made because it natively supports bidirectional communication and asynchronous calls, making it better suited for real-time interaction scenarios between models and tools.

You can think of MCP as a universal USB-C port: regardless of what runtime environment the Host on the left is, or what data or capabilities the Server on the right provides, as long as both sides follow the MCP protocol standard, they can connect directly.

This is the qualitative leap from M×N to M+N—integration difficulty drops by an order of magnitude. With 10 models plus 50 tools, you only need to maintain 60 sets of standardized integration code, rather than 500 sets of custom code. For tool providers, implementing an MCP Server once makes it callable by all MCP-supporting models; for model providers, building in an MCP Client enables connection to the entire MCP tool ecosystem.

Architecture Breakdown: How Host, Client, and Server Collaborate

MCP adopts a clear three-layer architecture where each layer has its own responsibilities. Understanding the division of labor between Host, Client, and Server is the key to mastering the MCP protocol.

Background: MCP's Transport Layer Mechanisms

MCP supports two primary transport modes: stdio (standard input/output) and SSE (Server-Sent Events). The stdio mode is suitable for local inter-process communication—the Host directly launches a Server subprocess and exchanges messages through pipes, with extremely low latency, ideal for local tools like file systems and code execution environments. The SSE mode is based on HTTP long connections, suitable for remote Server deployment scenarios, allowing Servers to proactively push events to Clients. This dual-mode design balances local security with remote extensibility, and is a key design decision enabling MCP to serve both individual developers and enterprise-grade deployments.

MCP Host: The Runtime Environment for Agents

The block on the left side of the architecture is the MCP Host—the host layer. Think of it as the Agent's brain and home, responsible for reasoning and decision-making, and for interacting with users.

Previously, this "home" needed rewiring every time a new "appliance" was purchased. Not anymore—the Host only needs to install a standard MCP Client to gain the potential to connect all "appliances." The Client serves as the standardized bridge between the Host and the external world.

Common MCP Hosts include: Claude Desktop, Cursor editor, various AI IDEs, and enterprise-built Agent runtime platforms. Their common characteristic is having built-in MCP Clients that can discover and connect to MCP Servers.

MCP Client: The Standardized Bridge Between Host and Server

The MCP Client is an easily overlooked but critically important layer in the architecture. It runs inside the Host and manages the connection lifecycle with MCP Servers, including service discovery, capability negotiation, and message transport. Each Client instance typically maintains a one-to-one connection with a Server, and the Host can run multiple Client instances simultaneously to connect to different Servers.

MCP Server: Standardized Encapsulation of Tool Capabilities

The green blocks on the right side of the architecture are MCP Servers—the capability providers. Whether you're a local file system, a company's SQL database, or a complex third-party API, you just need to wrap your functionality according to MCP protocol standards to become a standard Server.

Here's a crucial mindset shift: you don't need to beg the LLM to adapt to you. As long as you have the standard interface ready, any model supporting MCP can directly call your service. This dramatically lowers the barrier to entry for tool providers and is the fundamental reason the MCP ecosystem can expand rapidly.

Three Core Primitives: How Resources, Tools, and Prompts Work

MCP defines three fundamental interaction primitives that form the cornerstone of the entire protocol. Understanding these three primitives means understanding all the ways data flows and capabilities are invoked in MCP.

Resources: Providing Read-Only Context to Models

Resources are read-only contextual information. For example, having the model read today's system logs or view a database schema. The model can only look—it cannot modify.

This solves the problem of models obtaining contextual information, essentially providing the model with "reading material." Typical Resources include: file contents, database table structures, API documentation, configuration information, etc. Resources are identified by URIs, and models can request specific resources on demand.

Tools: Giving Models Real Execution Capabilities

Tools are the core of the three primitives and the most practically valuable part. Models can pass parameters to execute real functions—such as creating a GitHub Issue or querying last year's sales figures from a database.

With Tools, models truly gain "hands"—the ability to act on the world, not just observe it.