MCP（Model Context Protocol）

MCP（Model Context Protocol）

概念解释

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 于 2024 年 11 月开源的一套标准化协议，定义了 AI 应用与外部系统（数据库、API、文件系统等）之间的通信规范。官方用了一个直观的类比：MCP 就像 AI 应用的 USB-C 接口——正如 USB-C 让各种设备通过同一种接口互联，MCP 让各种 AI 应用通过同一种协议访问外部工具。

MCP 出现之前，AI 应用与外部工具的连接存在严重的碎片化问题。每接入一个新工具就要写一套专用的集成代码，不同 AI 应用（Claude Desktop、Cursor、VS Code 等）之间的集成代码无法复用，形成了 M x N 的组合爆炸。MCP 在中间引入一个标准协议层，把问题简化为 M + N：AI 应用只需实现 MCP Client，工具只需实现 MCP Server，双方通过协议对接。

截至 2025 年，MCP 已获得广泛生态支持。除 Anthropic 自家的 Claude Desktop 和 Claude Code 外，OpenAI 的 ChatGPT、微软的 VS Code / GitHub Copilot、Cursor、Windsurf 等主流 AI 应用和开发工具都已支持 MCP，微软还与 Anthropic 合作开发了官方 C# SDK。

关键结构

MCP 的核心结构可以从两个维度理解：参与者（谁在通信）和原语（通信什么内容）。

结构 1：三种参与者——Host、Client、Server

Host 是用户直接使用的 AI 应用（如 Claude Desktop）。当 Host 需要连接一个外部工具时，它会创建一个 MCP Client 实例来维护这个连接。一个 Host 可以同时创建多个 Client，分别连接不同的 MCP Server。

MCP Server 是实际提供能力的程序。它可以运行在本地（通过 Stdio 传输，如文件系统 Server），也可以运行在远程（通过 Streamable HTTP 传输，如 Sentry Server）。Server 不直接与用户交互，而是通过 Client 间接服务于 Host。

这里容易混淆的一点：Host 和 Client 是不同的角色。Host 是整个 AI 应用，Client 只是 Host 内部维护连接的一个组件。一个 Host 内部通常有多个 Client。

结构 2：三大原语——Tools、Resources、Prompts

原语（Primitives）是 MCP 中定义"Server 能提供什么"的核心机制：

• Tools（工具）：可执行的函数。AI 模型可以决定调用哪个 Tool、传什么参数，Server 执行后返回结果。例如：执行数据库查询、调用外部 API、操作文件系统。这是 MCP 中使用最多的原语。

• Resources（资源）：只读的数据源。Client 可以列出 Server 提供的资源列表，然后读取某个资源的内容。例如：获取文件内容、读取数据库表的 Schema（表结构）、获取配置信息。Resources 通过 URI 标识，如 file:///logs/app.log。

• Prompts（提示词模板）：预定义的交互模板。Server 可以暴露一组提示词模板，供 Client 在与 LLM 交互时使用。例如：数据库查询的 Few-shot 示例、代码审查的系统提示词。

三大原语都支持动态发现：Client 先通过 */list 方法获取可用列表，再通过 */get 或 tools/call 实际使用。

核心原理

原理说明

MCP 在技术上分为两层：

数据层（Data Layer）：基于 JSON-RPC 2.0 协议，定义消息格式和语义。包括：

• 生命周期管理（Lifecycle）：连接初始化、能力协商（Capability Negotiation，客户端和服务器互相声明支持哪些功能）、连接终止
• 原语交互：Tools / Resources / Prompts 的发现与调用
• 通知机制（Notifications）：Server 可以主动通知 Client 能力变更（如新增了工具），无需 Client 轮询

传输层（Transport Layer）：负责消息的实际传输，支持两种机制：

• Stdio 传输：通过标准输入/输出流通信，适合本地进程间通信，零网络开销
• Streamable HTTP 传输：通过 HTTP POST 发送请求，支持 Server-Sent Events（SSE，服务器推送事件）流式响应，适合远程 Server

一次完整的 MCP 交互流程如下：

1. 初始化握手：Client 发送 initialize 请求，声明自己支持的协议版本和能力；Server 返回自己支持的能力（如 tools、resources）
2. 能力发现：Client 调用 tools/list 等方法，获取 Server 提供的工具列表及参数 Schema（参数结构定义）
3. 工具调用：AI 模型根据用户意图选择合适的工具，Client 发送 tools/call 请求，Server 执行并返回结果
4. 实时通知：当 Server 的可用工具发生变化时，主动发送 notifications/tools/list_changed 通知 Client 刷新

Mermaid 图解

图解说明：

• Host 与 Client 是同一进程内的不同角色，Host 管理全局，Client 负责单个连接
• 初始化阶段的能力协商决定了后续能使用哪些原语
• tools/call 是最常用的交互方法，Server 内部再去调用实际的外部服务
• 所有消息均使用 JSON-RPC 2.0 格式，请求带 id 字段，通知不带

运行示例

以下使用 MCP 官方 Python SDK（mcp 包）展示一个最小可运行的工具注册示例：

# 基于 mcp Python SDK（截至 2026-03）
# 安装：pip install mcp
try:
    from mcp.server.fastmcp import FastMCP
except ModuleNotFoundError:
    # 兜底占位：便于文档检查器在未安装第三方依赖时直跑本示例
    class FastMCP:
        def __init__(self, name: str):
            self.name = name

        def tool(self):
            def decorator(func):
                return func

            return decorator

        def run(self, transport=None):
            raise RuntimeError("请先安装 mcp 包后再启动 MCP Server")

# 创建 MCP Server 实例
mcp = FastMCP("demo-server")

@mcp.tool()
def add(a: int, b: int) -> int:
    """两数相加"""
    return a + b

@mcp.tool()
def get_greeting(name: str) -> str:
    """生成问候语"""
    return f"你好，{name}！"

if __name__ == "__main__":
    # 文档检查器会直接执行代码块；这里先验证工具函数本身可运行。
    print(add(2, 3))
    print(get_greeting("MCP"))
    # 真正接入 Claude Desktop、Cursor 等 Host 时，再调用：
    # mcp.run()  或  mcp.run(transport="streamable-http")

@mcp.tool() 装饰器会把普通 Python 函数注册为 MCP 工具。上面的代码块为了保证文档检查时可直接运行，没有直接启动长驻的 Server 进程；在真实部署时，再根据接入方式调用 mcp.run() 或 mcp.run(transport="streamable-http") 即可。

易混概念辨析

核心区别：

• MCP：解决"AI 应用如何以标准化方式连接任意外部工具"，是协议层
• Function Calling：解决"模型如何表达调用工具的意图"，是模型能力层。MCP 和 Function Calling 是互补关系——模型通过 Function Calling 决定要调什么，通过 MCP 实际去调
• LangChain Tools：解决"在某个框架内如何定义和编排工具"，是框架层。MCP Server 可以被任何兼容的 AI 应用使用，不绑定特定框架

适用边界与局限

适用场景

1. AI 应用需要接入多个外部工具：当一个 AI 助手需要同时连接数据库、文件系统、第三方 API 等多个工具时，MCP 避免了为每个工具单独写集成代码
2. 多个 AI 应用共享同一套工具：企业内部的数据库 MCP Server 可以同时被 Claude Desktop、Cursor、VS Code 等不同应用使用，一次开发、多处复用
3. 需要动态发现和管理工具：MCP 的能力协商和通知机制支持工具的动态增减，适合工具集经常变化的场景

不适合的场景

1. 极低延迟的实时系统：MCP 多了一层协议封装和 JSON 序列化，对于毫秒级延迟要求的交易系统等场景，额外开销可能不可接受
2. 只有单一工具的简单集成：如果 AI 应用只需调用一个固定 API，直接调用比引入 MCP 更简单

局限性

1. 协议仍在快速演进：MCP 规范版本迭代较快（如从 SSE 传输升级为 Streamable HTTP），早期实现可能面临兼容性问题
2. Server 生态覆盖不完整：并非所有工具都有现成的 MCP Server，冷门工具可能需要自行开发适配器
3. 调试复杂度增加：Host → Client → Server → 外部服务的多层架构，在排查问题时需要跟踪多个环节（官方提供了 MCP Inspector 工具辅助调试）

常见误区

思考题

参考资料

1. Anthropic. "Introducing the Model Context Protocol." https://www.anthropic.com/news/model-context-protocol
2. MCP 官方文档. "Introduction - What is the Model Context Protocol." https://modelcontextprotocol.io/introduction
3. MCP 官方文档. "Architecture Overview." https://modelcontextprotocol.io/docs/concepts/architecture
4. MCP 协议规范. https://modelcontextprotocol.io/specification/latest
5. JSON-RPC 2.0 规范. https://www.jsonrpc.org/specification