什么是 MCP(Model Context Protocol):一文讲清协议、客户端、和国内怎么用
TL;DR — MCP 是把 LLM 接外部工具这件事标准化的开放协议。模型厂商各自的 function calling 格式不兼容,开发者写一次工具要适配多家;MCP 反过来——工具用统一接口暴露,客户端(Claude Code、Cursor、ChatGPT 桌面端)通过 MCP client 适配各家模型。底层是 JSON-RPC 2.0,2025-11-25 spec 是当前最新版,已经从 Anthropic 私有移交到 Linux 基金会。国内用 ofox API 就能跑完整 MCP 工作流。
MCP 到底解决什么问题
想象一下你写了一个”查公司内部 ERP 库存”的工具。一年前这件事大概是这样的:
- 给 OpenAI 用:按 OpenAI Function Calling 的 JSON schema 写一份
- 给 Claude 用:按 Anthropic Tool Use 的 JSON schema 再写一份
- 给 Gemini 用:按 Google 的格式第三次写
- 桌面端 Claude 不能直接连你公司服务器——只能放到自家应用里调
三份代码做同一件事,加一个新模型就多一份适配。MCP 把这件事调换了方向:工具一次写好,模型那端通过 MCP client 适配。你写一个 MCP server,Claude Code、ChatGPT 桌面端、Cursor、OpenClaw、Cline,所有支持 MCP 的客户端都能直接连。
类比一下:MCP 之于 AI 工具生态,相当于 USB-C 之于充电线。不是新功能,是接口标准化。
架构:Host / Client / Server 三者关系
MCP 的官方架构有三个角色:
- Host:发起连接的 LLM 应用本身。比如 Claude Desktop、Cursor、OpenClaw 这些”装着 LLM”的程序
- Client:Host 内部用来连一个具体 server 的连接器。一个 Host 可以同时跑多个 Client,连多个 Server
- Server:提供工具、数据、模板的服务。可以是本地子进程(比如一个 Python 脚本),也可以是远程 HTTP 服务
通信走 JSON-RPC 2.0,有状态连接(不是 REST 那种无状态请求)。建立连接时双方先做能力协商——Server 告诉 Client 它支持哪些 primitive,Client 告诉 Server 自己支持什么客户端能力。
Server 能暴露什么:三种 primitive
这是 MCP 的核心。Server 通过三种东西给模型提供价值:
| Primitive | 是什么 | 例子 |
|---|---|---|
| Resources | 数据和上下文,给用户或模型读 | 文件内容、数据库查询结果、API 返回的 JSON |
| Prompts | 预定义的提示词模板和工作流 | ”总结这份会议纪要的待办事项”、“按公司风格审查这段代码” |
| Tools | 模型可以执行的函数 | 发邮件、查 ERP 库存、跑 SQL、读 Notion 页面 |
Tools 是大头,也是最危险的部分,因为它意味着任意代码执行。spec 里专门有一节讲安全:Host 必须先得到用户明确同意才能让模型调用 Tool,工具的描述(描述模型应该怎么用它)应被视作”不可信”,除非来自可信源。这一条很重要,prompt injection 攻击经常发生在工具描述里。
Client 能反向给 Server 什么
很多人以为 MCP 是单向的:Server 提供能力,Client 调用。其实是双向的。Client 也能给 Server 提供三种能力:
- Sampling:Server 反过来调 Client 的 LLM。比如一个文档分析 Server 调用一次”总结这段”
- Roots:告诉 Server 它能操作的范围。比如允许的文件系统目录
- Elicitation:Server 向用户索取额外信息。比如运行到一半发现缺参数,弹个对话框让用户补充
这套设计让 MCP server 可以做相当复杂的 agentic 工作流,不只是单次调用。
2025-11-25 spec:最新的传输层和认证变化
MCP 已经发了好几版规范。当前最新是 2025-11-25 spec,几个关键变化。
第一,Streamable HTTP 取代 SSE。早期 spec 里远程 server 用 Server-Sent Events 做单向流,问题不少:断线恢复差,代理穿透麻烦。2025 年 11 月引入的 Streamable HTTP 用标准 HTTP 长连接,更适合放在 CDN 和负载均衡器后面,也更适合做云部署。
第二,OAuth 2.1 成为远程认证标准。这个是 2025 年 6 月 spec 定的,到 11 月已经稳定。远程 MCP server 走 OAuth 2.1,不要再用裸 API Key。这对企业部署很重要,可以接 SSO、做权限分发。
第三,2026 路线图是无状态化。当前 server 还是有状态的,每个连接维持 session,这限制了横向扩展。2026 年的方向是把 session 的创建、恢复、迁移标准化,让 server 重启或扩缩容时客户端无感。这一条还没落地,但路标已经画好。
治理变化:MCP 不再属于 Anthropic
2025 年 12 月,Anthropic 把 MCP 捐给了 Agentic AI Foundation(AAIF),这是 Linux Foundation 下的一个定向基金,由 Anthropic、Block、OpenAI 联合发起。
为什么重要?MCP 一开始是 Anthropic 单家推的协议,社区担心”这是不是又一个厂商锁定”。捐给 Linux 基金会之后,MCP 成了中立开放标准,OpenAI、Google 这些厂商更愿意接。事实上 ChatGPT 桌面端 2025 年下半年开始支持 MCP,Gemini 在 SDK 层也有相关适配。
意思是:写 MCP server 不是押宝某家,是押在一个跨厂商的标准上。
MCP vs Function Calling:什么时候用哪个
简单说:
- Function Calling:单次工具调用,工具数量少,集成在自己代码里。比如你写一个客服 bot,自己定义 3 个工具。直接用模型厂商的 Function Calling 就行
- MCP:工具是独立的、需要被多个 AI 客户端复用的能力。比如你给团队写了一个”查公司知识库”的工具,希望大家在 Claude Code、Cursor、ChatGPT 桌面端都能用,那就做成 MCP server。具体怎么用 Python 写,参见 MCP 协议实战:用 FastMCP 搭 Server
具体技术细节可以对照 Claude function calling 完全教程,那篇文章讲的是单模型场景下怎么定义工具。MCP 是把这个能力跨模型/跨客户端复用。
现成的 MCP 生态
写新 server 之前先看看现成的。MCP 社区现在已经有几百个开源 server:
- 文件系统:读写本地文件
- GitHub:查 issue、读 PR、提交 commit
- 数据库:PostgreSQL、SQLite、MongoDB 都有官方或社区 server
- 浏览器:Playwright/Puppeteer 的 MCP 封装
- Notion / Linear / Slack:常见 SaaS 都有
- Chrome DevTools:MCP server 可以让模型直接调 Chrome 调试协议
客户端这边支持 MCP 的有:Claude Desktop / Claude Code、Cursor、Cline、Continue、OpenClaw、Kilo、Codex、Zed、Chatbox。基本上 2026 年的主流 AI 编程客户端都支持。
OpenClaw 这边的配置可以参考 OpenClaw 初始化配置完全指南,settings 里有专门的 MCP 配置入口。
国内开发者怎么跑 MCP
MCP client 端本身不依赖任何境外服务。客户端是装在你电脑上的程序,MCP server 一般也跑在你机器上或自家服务器。真正的瓶颈在后面的模型 API。
用 ofox 接 Claude Sonnet 4.6 跑 MCP 工作流的最小配置(以 Claude Code 为例):
# 环境变量指向 ofox 的 Anthropic 原生端点
export ANTHROPIC_BASE_URL="https://api.ofox.ai/anthropic"
export ANTHROPIC_AUTH_TOKEN="<你的 ofox key>"
export ANTHROPIC_MODEL="anthropic/claude-sonnet-4.6"
# 启动 Claude Code,自动读取本地 MCP server 配置
claude
OpenAI 兼容客户端(OpenClaw、Cline、Roo Code 等)改成:
# base URL 指向 ofox 的 OpenAI 兼容端点
OPENAI_BASE_URL="https://api.ofox.ai/v1"
OPENAI_API_KEY="<你的 ofox key>"
模型可以换 GPT-5.4、Claude Sonnet 4.6、Gemini 3.1 Pro 这些都行。模型选型逻辑可以参考 Claude Opus 4.7 完全指南 里的对比表。
MCP server 这一端跟模型走哪家无关,你的 server 只跟 client 通信,client 再去调底层 LLM。换 base URL 不需要改 server 代码。
常见踩坑
MCP server 起不来。多半是 stdio 子进程的 PATH 问题:本地装了 nvm/conda,但 Claude Desktop 的环境变量里没继承到。解决方法是在 server 配置里显式写绝对路径,比如 /Users/foo/.nvm/versions/node/v20.10.0/bin/node。
工具调用了但模型没反应。通常是工具描述写得太短,模型没明白什么时候该调它。MCP tool 的 description 字段建议写完整的”什么场景下用这个工具、输入什么、返回什么”,不要只写”查询库存”五个字。
远程 MCP server 鉴权失败。OAuth 2.1 标准里有几个常见坑:PKCE 必须用(OAuth 2.1 强制要求,不像 2.0 那样可选)、redirect URI 必须严格匹配、Protected Resource Metadata(RFC 9728)要正确暴露、token 要带 audience。Claude Code 这边可以跑 claude --debug mcp 看 server 的 stderr 输出,或者在交互式会话里用 /mcp 命令查状态;Claude Desktop 的 MCP 日志在 ~/Library/Logs/Claude/mcp*.log。
模型 API 报 429 / 529。这是模型那端限流,不是 MCP 本身的问题。可以参考 AI API 报错大全。
一句话总结
MCP 把”AI 用工具”这件事从厂商各搞一套变成了一个开放标准,写一次工具到处能跑。2025 年底捐给 Linux 基金会之后,它实际上已经成了跨厂商共识。国内开发者跑 MCP 没有协议层障碍,把模型 API 走 ofox 就行,client、server、协议都是开放的。
如果你接下来要做 AI Agent,先看看现成的 MCP server,能省一半工作。
进一步阅读
- 官方 spec:modelcontextprotocol.io/specification/2025-11-25
- 官方 server 仓库:github.com/modelcontextprotocol/servers
- 上下文工程长文:Claude AI Agent 长上下文实战
- 编程客户端横评:Vibe Coding 工具横评

