06 - MCP 模型上下文协议：统一 AI 工具的“Type-C 接口“
这是"从 LLM 到 Agent Skill"系列的第六篇。上一篇讲了 Tool 让模型能"调用"外部函数。但这里有个工程痛点——每个 AI 平台的工具接入方式都不一样。这一篇，我们聊聊正在改变这个局面的协议：MCP。
一、工具接入的"巴别塔"困境
让我们回到上一篇的场景：你写了一个get_weather函数，想让大模型能调用它。
然后你发现：
OpenAI要求的工具描述格式是这样的……
Anthropic（Claude）要求的格式是那样的……
Google Gemini又搞了一套自己的……
国内的通义千问 / 文心一言 / DeepSeek也各有各的规范……
同一个get_weather，你需要写 5 套接入代码：
get_weather ├── openai_adapter.py # 适配 OpenAI 格式 ├── anthropic_adapter.py # 适配 Anthropic 格式 ├── gemini_adapter.py # 适配 Google 格式 ├── qwen_adapter.py # 适配通义千问格式 └── deepseek_adapter.py # 适配 DeepSeek 格式
这跟当年手机充电接口的情况一模一样——每个厂商都有自己的标准，出门要带一捆数据线。
二、MCP 是什么？
MCP（Model Context Protocol，模型上下文协议）就是来解决这个问题的。
MCP 是一套统一的工具接入标准协议。开发者按 MCP 规范写一次工具，该工具即可在所有支持 MCP 的 AI 平台上通用。
它由 Anthropic 在 2024 年底提出，目前正在快速获得社区和各大平台的支持。
2.1 一个直觉类比
手机充电接口的演变： 过去：Micro-USB、Lightning、30-pin、磁吸……各搞各的 现在：Type-C 一统天下（至少在物理接口层面） AI 工具的演变： 过去：OpenAI Function、Anthropic Tool、Google Function……各搞各的 未来：MCP 一统天下
MCP 就是 AI 世界的"Type-C 接口"。
三、MCP 的核心架构
MCP 协议定义了三类角色：
┌──────────┐ MCP 协议 ┌──────────┐ │ │ ←──────────────→ │ │ │ MCP Host │ │ MCP Server│ │ (AI 客户端) │ │ (工具提供方)│ │ │ │ │ └──────────┘ └──────────┘ │ │ │ MCP 协议 │ 实现具体工具 │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ MCP Client│ │ 天气 API │ │ (SDK) │ │ 文件系统 │ └──────────┘ │ 数据库 │ │ …… │ └──────────┘
| 角色 | 是什么 | 举例 |
|---|---|---|
| MCP Host | AI 应用本身 | Claude Desktop、VS Code + Claude、ChatGPT |
| MCP Client | 协议客户端，与 Server 通信 | 内嵌在 Host 中的 SDK |
| MCP Server | 工具的提供方 | 天气查询 Server、文件操作 Server、数据库 Server |
3.1 通信方式
MCP 支持两种传输方式：
| 方式 | 场景 | 说明 |
|---|---|---|
| stdio（标准输入输出） | 本地进程 | MCP Server 作为一个子进程运行，通过标准输入输出通信 |
| HTTP + SSE | 远程服务 | MCP Server 作为远程 HTTP 服务，通过 Server-Sent Events 推送 |
四、MCP Server 的"工具暴露"
一个 MCP Server 启动后，会向 Host 暴露它拥有的工具列表。模型就能看到这些工具，并在需要时"调用"它们。
举个例子，一个天气 MCP Server 暴露的能力可能是：
{ "tools": [ { "name": "get_current_weather", "description": "获取指定城市的实时天气", "parameters": { "city": "城市名", "unit": "温度单位，celsius 或 fahrenheit" } }, { "name": "get_forecast", "description": "获取未来7天的天气预报", "parameters": { "city": "城市名", "days": "预报天数，1-7" } } ] }这套描述是平台无关的。OpenAI、Anthropic、Google 都能消费同一份描述。
五、MCP 的生态现状
5.1 官方支持
| 平台 | MCP 支持情况 |
|---|---|
| Claude Desktop | 原生支持 |
| Claude Code | 原生支持 |
| VS Code / Cursor | 通过插件支持 |
| OpenAI | 2025 年宣布支持 |
| Google Gemini | 跟进中 |
| Continue / Cody | 社区集成中 |
5.2 社区 MCP Server 示例
社区已经涌现了大量开箱即用的 MCP Server：
文件系统 Server：让 AI 读写本地文件
GitHub Server：让 AI 管理 Issue、PR、仓库
Postgres / SQLite Server：让 AI 直连数据库查询
Slack Server：让 AI 收发 Slack 消息
Puppeteer Server：让 AI 操控浏览器
天气 / 地图 / 新闻 Server：各种实时数据
大部分 MCP Server 的安装只需要一行配置：
{ "mcpServers": { "weather": { "command": "npx", "args": ["-y", "@anthropic/mcp-server-weather"] } } }六、MCP 的局限性
MCP 并不是完美的，目前有几个值得关注的问题：
6.1 协议仍处于早期
MCP 规范还在快速迭代中，API 可能发生 breaking change。目前生态还不够成熟。
6.2 安全考量
MCP Server 本质上是在本地执行的外部程序。如果安装了来源不明的 MCP Server，它可能有权限读取你的文件、访问你的网络。需要像对待 npm 包一样审慎。
6.3 不是所有平台都跟进了
虽然 OpenAI 和 Google 表达了支持，但实际的集成深度和进度各不相同。MCP 成为真正通用的标准还需要时间。
七、MCP 和 Tool 的关系
回到上一篇的内容：
Tool是单个函数（
get_weather）MCP是工具的包装和传输标准（怎么描述、怎么发现、怎么调用、怎么返回）
打个比方：
| 概念 | 类比 |
|---|---|
| Tool | 一个 App（比如微信） |
| MCP | 应用商店的接口标准（App 怎么上架、怎么下载、怎么更新） |
同样的 Tool，可以用 MCP 协议来发布，也可以用 OpenAI 原生格式来对接。MCP 的价值在于一套描述到处跑。
八、总结
不同 AI 平台的工具接入规范不同，导致同一个工具需要写多套适配代码。
MCP 是统一的工具接入标准协议，类比 Type-C——一次开发，多处通用。
MCP 定义了 Host-Client-Server 三层架构，支持 stdio 和 HTTP 两种通信方式。
MCP 生态正在快速成长，但协议仍处早期，安全和成熟度需要关注。
下一篇，我们将工具调用 + 自主决策结合起来，聊聊 AI 应用的终极形态——Agent（智能体）。
本系列文章：
LLM 大语言模型
Token 与 Tokenizer
Context 与 Context Window
Prompt 提示词
Tool 工具调用
MCP 模型上下文协议← 你在这里
Agent 智能体（待发布）
Agent Skill（待发布）