MCP stands for Model Context Protocol. It is an open standard introduced by Anthropic in November 2024 that standardizes how AI applications communicate with external data sources and tools.
Think of it as the USB-C port for AI applications — a universal, standardized interface that lets any AI model (Claude, GPT, DeepSeek, etc.) plug into any external tool, database, or service without custom integration code.
CN:
MCP 全称 Model Context Protocol（模型上下文协议） 。它是 Anthropic 在 2024 年 11 月推出的一个开放标准，用于标准化 AI 应用与外部数据源和工具之间的通信方式。
你可以把它理解为 AI 应用的 USB-C 接口 —— 一个通用的标准化接口，让任何 AI 模型（Claude、GPT、DeepSeek 等）都能即插即用地接入任何外部工具、数据库或服务，而无需编写定制化的集成代码。
MCP Architecture Overview — Core Concepts
MCP follows a client-host-server architecture.
3.1 Three Core Participants
三个核心角色
① Host（主机） — The AI application itself (e.g., Claude Desktop, Claude Code, an IDE).
The host acts as the container and coordinator:
- Creates and manages multiple client instances
- Controls client connection permissions and lifecycle
- Enforces security policies and consent requirements
- Handles user authorization decisions
- Coordinates AI/LLM integration and sampling
- Manages context aggregation across clients
② Client（客户端） — Created by the host, each client maintains a 1:1 dedicated connection with exactly one server.
Each client:
- Communicates with exactly one server
- Attaches protocol version and capabilities to every request
- Routes protocol messages bidirectionally
- Manages subscriptions and notifications
- Maintains security boundaries between servers
③ Server（服务器） — A program that provides specialized context and capabilities to AI applications.
Each server:
- Exposes Resources, Tools, and Prompts via MCP primitives
- Operates independently with focused responsibilities
- Can be local processes (STDIO transport) or remote services (HTTP/SSE transport)
- Must respect security constraints — cannot read the whole conversation or “see into” other servers
CN:
① Host（主机） — AI 应用本身（如 Claude Desktop、Claude Code、IDE）。
- 创建和管理多个客户端实例
- 控制客户端连接权限和生命周期
- 执行安全策略和同意要求
- 处理用户授权决策
- 协调 AI/LLM 集成和采样
- 管理跨客户端的上下文聚合
② Client（客户端） — 由主机创建，每个客户端与一个服务器保持 1:1 专属连接。
每个客户端：
- 只与一个服务器通信
- 在每个请求中附加协议版本和能力信息
- 双向路由协议消息
- 管理订阅和通知
- 维护服务器之间的安全边界
③ Server（服务器） — 向 AI 应用提供专业上下文和能力的程序。
每个服务器：
- 通过 MCP 原语暴露 Resources（资源）、Tools（工具）和 Prompts（提示模板）
- 独立运行，职责聚焦
- 可以是本地进程（STDIO 传输）或远程服务（HTTP/SSE 传输）
- 必须遵守安全约束 —— 不能读取整个对话，也不能“看到”其他服务器
3.2 Two Layers
CN:
3.3 Three Core Primitives
三种核心原语
MCP servers expose three types of primitives to AI applications:
| Primitive | EN | CN | Control |
|---|---|---|---|
| Prompts | Pre-defined templates or instructions that guide language model interactions | 预定义的模板或指令，用于引导语言模型的交互 | User-controlled (用户控制) |
| Resources | Structured data or content that provides additional context to the model | 结构化的数据或内容，为模型提供额外的上下文 | Application-controlled (应用控制) |
| Tools | Executable functions that allow models to perform actions or retrieve information | 可执行的函数，允许模型执行操作或检索信息 | Model-controlled (模型控制) |
3.4 Design Principles
MCP is built on four key design principles:
1. Servers should be extremely easy to build（服务器应该极易构建）
- Host applications handle complex orchestration
- Servers focus on specific, well-defined capabilities
- Simple interfaces minimize implementation overhead
2. Servers should be highly composable（服务器应该高度可组合）
- Each server provides focused functionality in isolation
- Multiple servers can be combined seamlessly
- Shared protocol enables interoperability
3. Servers should not be able to read the whole conversation（服务器不应能读取完整对话）
- Servers receive only necessary contextual information
- Full conversation history stays with the host
- Each server maintains isolation — cannot “see into” other servers
- Cross-server interactions are controlled by the host
4. Features can be added progressively（功能可渐进式添加）
- Core protocol provides minimal required functionality
- Additional capabilities can be negotiated as needed
- Backwards compatibility is maintained
CN:
1. 服务器应该极易构建
- 主机应用处理复杂的编排工作
- 服务器聚焦于具体、明确定义的能力
- 简单接口最小化实现开销
2. 服务器应该高度可组合
- 每个服务器独立提供聚焦的功能
- 多个服务器可以无缝组合
- 共享协议实现互操作性
3. 服务器不应能读取完整对话
4. 功能可渐进式添加
3.5 Capability Negotiation
MCP uses a capability-based negotiation system. During initialization, clients and servers explicitly declare what features they support.
- Servers declare: tool support, resource subscriptions, prompt templates
- Clients declare: sampling support, elicitation handling
- Both parties must respect declared capabilities throughout the session
- Additional capabilities can be negotiated through protocol extensions
This ensures clients and servers have a clear understanding of supported features while keeping the protocol extensible.
CN:
MCP 使用 基于能力的协商系统 。在初始化期间，客户端和服务器明确声明它们支持的功能。
这确保客户端和服务器对支持的功能有清晰的理解，同时保持协议的可扩展性。
3.6 Stateful vs Stateless
有状态 vs 无状态
Important note: The MCP specification has evolved. Earlier versions (2025-06-18) described MCP as a “stateful session protocol.” However, the July 28, 2026 revision made MCP stateless at its core — every request is self-contained and carries its own protocol version and capabilities.
This change:
- Removes the need for session affinity
- Simplifies horizontal scaling and load balancing
- Makes the protocol easier to operate at scale
For our learning purposes, we’ll focus on the current stateless model while understanding that the SDKs abstract away most of these concerns.
CN:
重要提示： MCP 规范已经演进。早期版本（2025-06-18）将 MCP 描述为“有状态会话协议”。 但是，2026 年 7 月 28 日的修订 使 MCP 在核心层面变为 无状态 —— 每个请求都是自包含的，携带自己的协议版本和能力信息。
这一变化：
- 消除了对会话亲和性的需求
- 简化了水平扩展和负载均衡
- 使协议更易于大规模运维
就我们的学习目的而言，我们将聚焦于 当前的无状态模型，同时理解 SDK 抽象了大部分这些 concerns。