Tag: MCP

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

MCP consists of two layers:

Layer	EN	CN
Data Layer	Defines the JSON-RPC based protocol for client-server communication, including lifecycle management, and core primitives (tools, resources, prompts, notifications)	定义基于 JSON-RPC 的客户端-服务器通信协议，包括生命周期管理、核心原语（工具、资源、提示模板、通知）
Transport Layer	Defines communication mechanisms and channels (STDIO, HTTP/SSE) for data exchange, including connection establishment, message framing, and authorization	定义通信机制和通道（STDIO、HTTP/SSE），包括连接建立、消息帧和授权

CN:

MCP 由两层组成：

层	EN	CN
数据层	Defines the JSON-RPC based protocol for client-server communication, including lifecycle management, and core primitives (tools, resources, prompts, notifications)	定义基于 JSON-RPC 的客户端-服务器通信协议，包括生命周期管理、核心原语（工具、资源、提示模板、通知）
传输层	Defines communication mechanisms and channels (STDIO, HTTP/SSE) for data exchange, including connection establishment, message framing, and authorization	定义通信机制和通道（STDIO、HTTP/SSE），包括连接建立、消息

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:

MCP 建立在四个关键设计原则之上：

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 使用 基于能力的协商系统 。在初始化期间，客户端和服务器明确声明它们支持的功能。

• 服务器声明：工具支持、资源订阅、提示模板
• 客户端声明：采样支持、elicitation 处理
• 双方在整个会话期间必须遵守已声明的能力
• 额外能力可通过协议扩展协商

这确保客户端和服务器对支持的功能有清晰的理解，同时保持协议的可扩展性。

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。

Key Takeaways

要点	EN	CN
MCP 全称	Model Context Protocol, introduced by Anthropic in Nov 2024	模型上下文协议，Anthropic 于 2024 年 11 月推出
MCP 类比	USB-C port for AI applications	AI 应用的 USB-C 接口
架构模式	Client-Host-Server architecture	客户端-主机-服务器架构
三个核心角色	Host (coordinator) → Client (1:1 connection) → Server (capability provider)	主机（协调器）→ 客户端（1:1 连接）→ 服务器（能力提供者）
两层架构	Data Layer (JSON-RPC) + Transport Layer (STDIO/HTTP-SSE)	数据层（JSON-RPC）+ 传输层（STDIO/HTTP-SSE）
三种原语	Prompts (user-controlled), Resources (app-controlled), Tools (model-controlled)	Prompts（用户控制）、Resources（应用控制）、Tools（模型控制）
四大设计原则	Easy to build, Composable, Isolated (can’t read full conversation), Progressively extensible	易于构建、可组合、隔离（不能读完整对话）、渐进可扩展
能力协商	Clients and servers declare supported features during initialization	客户端和服务器在初始化时声明支持的功能
MCP vs REST	Complementary, not competing — MCP is AI-native, REST is general-purpose	互补而非竞争 —— MCP 是 AI 原生的，REST 是通用目的的
最新变化	July 2026 revision made MCP stateless at its core	2026 年 7 月修订使 MCP 在核心层面变为无状态