MCP（Model Context Protocol）是 Anthropic 在 2024 年底开源的协议标准，旨在为大模型与外部工具/数据源之间的交互建立统一规范。它正在成为 AI 工具调用领域的"USB-C接口"。
为什么需要 MCP
大模型本身不具备操作外部系统的能力。当前主流方案（OpenAI Function Calling、LangChain Tool 等）都在尝试解决"让 LLM 调用工具"这个问题，但各家实现方式不同，导致：
- 每个 LLM 提供商有自己的工具调用格式
- 工具提供方需要为不同平台分别适配
- 客户端（IDE、Agent 框架）难以统一对接
MCP 的目标很明确：定义一个开放的、与模型无关的协议，让 任意 LLM 客户端 和 任意工具服务端 可以通过同一套协议通信。
协议核心概念
MCP 定义了三种核心原语（Primitive）：
Tool（工具）：模型可以调用的操作。类似于函数调用，有输入参数和返回值。比如"搜索文件"、"执行 SQL"、"发送消息"。Tool 的核心特征是：由模型决定何时调用，属于 model-controlled。
Resource（资源）：模型可以读取的数据源。类似于 GET 请求，提供上下文信息但不产生副作用。比如"读取文件内容"、"获取数据库表结构"。Resource 是 application-controlled，由客户端决定何时读取。
Prompt（提示模板）：预定义的交互模板。由服务端提供，帮助用户构建特定场景的对话。比如"代码审查模板"、"SQL 生成模板"。Prompt 是 user-controlled，由用户主动选择。
这三种原语的控制权分别归属模型、应用和用户，设计上很清晰。
通信机制
MCP 基于 JSON-RPC 2.0 协议通信，支持两种传输方式：
stdio 传输：客户端以子进程方式启动 MCP Server，通过标准输入/输出通信。适合本地工具，比如 IDE 插件调用本地文件操作。优势是零配置、无需网络。
HTTP + SSE 传输：通过 HTTP POST 发送请求，通过 Server-Sent Events 接收响应流。适合远程服务。后来社区又提出了 Streamable HTTP 方案，用单一 HTTP 端点替代 SSE，更易于部署。
一次典型的 MCP 交互流程：
- 客户端发送
initialize请求，协商协议版本和能力 - 服务端返回支持的 Tool / Resource / Prompt 列表
- 客户端将工具描述注入到 LLM 的系统提示中
- LLM 根据用户输入决定是否调用某个 Tool
- 客户端通过 MCP 协议向服务端发送
tools/call请求 - 服务端执行操作并返回结果
- 客户端将结果反馈给 LLM，LLM 生成最终回答
与 OpenAI Function Calling 的对比
Function Calling 是 OpenAI 在 API 层面提供的工具调用能力，和 MCP 看起来类似但定位不同：
定位层面：Function Calling 是 API 特性，绑定 OpenAI 的模型服务；MCP 是通信协议，与模型无关。
范围层面：Function Calling 只覆盖"模型请求调用函数"这一步；MCP 覆盖了工具发现、调用、资源读取、提示模板等完整链路。
执行层面：Function Calling 中函数的实际执行由调用方自己处理；MCP 中工具执行由 MCP Server 负责，客户端只是中转。
生态层面：Function Calling 的工具定义分散在各个应用中；MCP Server 可以作为独立服务共享和复用。
可以这样理解：Function Calling 解决的是"模型怎么表达它想调用一个函数"，MCP 解决的是"工具怎么注册、发现、调用和通信"。两者不冲突，一个 MCP 客户端完全可以在内部使用 Function Calling 来让模型决策。
MCP Server 的实现
MCP 官方提供了 TypeScript 和 Python 两套 SDK。一个 MCP Server 本质上就是一个实现了 MCP 协议的服务进程。
以 Python SDK 为例，实现一个 MCP Server 的基本结构是：使用 @server.tool() 装饰器注册工具，每个工具有名称、描述、参数 schema 和执行逻辑。Server 启动后通过 stdio 或 HTTP 监听客户端请求。
目前社区已经涌现了大量 MCP Server 实现：
- 文件系统：读写本地文件、目录操作
- 数据库：PostgreSQL、MySQL、SQLite 查询
- Web 搜索：Brave Search、Google Search
- 开发工具：Git 操作、GitHub API、Docker 管理
- 知识库：Notion、Obsidian、本地向量库
- 浏览器：Puppeteer、Playwright 自动化
这些 Server 可以被任何支持 MCP 的客户端直接使用，这就是标准化带来的价值。
安全考量
MCP 在设计上需要面对几个安全问题：
权限控制：MCP Server 拥有执行实际操作的能力（读写文件、执行命令、访问数据库），需要严格的权限边界。当前的做法是在客户端侧做确认弹窗（比如 Claude Desktop 会在执行 Tool 前请求用户批准），但这不够系统化。
Prompt Injection：恶意内容可能通过 Resource 注入到 LLM 上下文中，诱导模型执行非预期的 Tool 调用。这是所有 LLM + 工具方案的通病，MCP 尚未在协议层面给出解决方案。
Server 信任：用户安装第三方 MCP Server 时，需要信任其代码。目前没有签名验证或沙箱机制。
这些问题并非不可解，但确实需要协议的持续演进。
生态发展
MCP 在 2025 年初迅速获得了行业认可：
- Anthropic 的 Claude Desktop 和 Claude Code 原生支持 MCP
- Cursor、Windsurf 等 AI IDE 集成了 MCP 客户端
- OpenAI 在 2025 年 3 月宣布在其产品中支持 MCP
- Google 的 ADK（Agent Development Kit）也加入了 MCP 支持
这意味着 MCP 正在从 Anthropic 的单方面提案变成行业共识。当主要的 LLM 提供商和 AI 工具厂商都采纳同一个协议时，工具生态就能真正实现互通。
展望
MCP 目前还在快速迭代中，有几个值得关注的方向：
- 身份认证和授权：协议层面的 OAuth 集成正在推进
- Server 注册与发现：类似包管理器的 MCP Server registry
- 多步骤编排：当前 MCP 是单次调用模式，未来可能支持 Server 之间的编排
- 性能优化：批量调用、流式结果返回等
MCP 不是万能的，但它在正确的时间解决了一个真实的问题。当 AI Agent 越来越多地需要与外部世界交互时，一个标准化的工具调用协议是基础设施级别的需求。
