什么是 MCP(Model Context Protocol)?AI 界的 USB-C

如果你用过 Claude Desktop 连文件系统,或在 AI 工具里看过「Connect to GitHub」按钮,你已经在用 MCP 了。Model Context Protocol 是 Anthropic 2024 年底推出的开放协议,让 LLM 应用能通过统一接口跟外部工具沟通。一年多后,它已经是 AI 工具圈的主流集成协议 — Claude、Cursor、Windsurf、Continue、好几十个 agent 都采用。

MCP 解决什么问题

MCP 出现之前,每个想读你 Notion、GitHub、数据库、本地文件的 AI app,都要为每个数据源各自写一份集成。Cursor 的 GitHub 支持是一份 code,Claude Desktop 的 GitHub 支持是另一份,Windsurf 又是另一份。工具方(GitHub、Notion、Linear)也得跟每个 AI 客户端各别写(或求他们写)集成。

MCP 把这件事压成一个协议:

MCP server 暴露工具、资源、prompt。每个数据源或服务一个 server:GitHub server、Postgres server、文件系统 server。
MCP client 是 AI app。Claude Desktop、Cursor、Windsurf — 全部讲同一套协议。
任意 client × 任意 server = 可运行的集成。N×M 集成问题变成 N+M。

类比:MCP 之于 AI 集成,就像 USB-C 之于充电器。一个协议、即插即用,所有东西突然都能跟所有东西接。

MCP server 实际暴露什么

用协议的话讲,三件事:

Tools — 模型可以调用的函数。每个工具有名称、描述、输入的 JSON schema。一个 GitHub MCP server 可能暴露 list_pull_requests、create_issue、get_file_contents。何时调用由模型决定。

Resources — 模型可以拉进来当 context 的只读数据。文件系统 server 暴露文件;数据库 server 暴露表。Resource 可以由 user 主动浏览(「把这个文件附到对话」)或由模型自主抓。

Prompts — server 提供的常用 prompt 模板。GitHub server 可能提供「总结这个 PR」的模板,user 从菜单就能 invoke。

大多数 server 主力放在 tools — 那才是动作所在。

实际长什么样

Claude Desktop 装了文件系统 MCP server:

你问:「我 ~/projects/builderworld 文件夹里有什么?」
Claude 调用文件系统 MCP server 的 read_directory。
Server 回目录清单。
Claude 念给你听,顺便建议打开某个文件。
你同意,Claude 调用 read_file 拿内容。

从 user 角度,Claude 就是「会」读文件。从开发者角度,整个文件系统集成是一个 ~200 行的 Python 或 TypeScript MCP server,任何支持 MCP 的 client 都能用。

现在怎么用 MCP

如果你是使用者:大多数主流 AI client 都支持 MCP,从 registry 一键安装。Claude Desktop 里进设置、浏览可用 MCP server(filesystem、GitHub、Slack、Postgres、Notion 等)、安装、授权。Cursor、Windsurf、大部分 coding agent 也有类似 UI。

如果你是 builder:你可以为自家产品/数据写 MCP server。SDK 有 TypeScript、Python、Rust 等。最小可行 server:定义几个 tool、跑 stdio 或 HTTP transport、跟 client 注册。简单 server 一个下午做得出来。

社区最大的 server registry 在 modelcontextprotocol.io 跟 GitHub 上。从数据库到设计工具,几百个都有。

为什么这比看起来重要

MCP 不只是集成管线 — 它改变激励结构。

对工具方来说,写一个 MCP server 就跟整个 AI client 生态兼容。Notion 写一个 server,可以在 Claude、Cursor、未来的 ChatGPT、所有未来 AI 工具被使用。比起一对一集成 deal,投资回报率好太多。

对 AI client 来说,MCP 等于不用自己写就有上千个集成。Cursor 的价值不是写 Slack 集成,是做一个好 IDE。MCP 让集成由其他人负责。

对 user 来说,MCP 代表「我今天用的 AI,明天可能因为新 server 上架而获得新能力,不用 app 更新」 — 装个 server 就好。

Meta 效应:一个低耦合的健康生态,AI client 跟工具 server 可以各自演化。

什么时候不要用 MCP

**一次性脚本。**只需要从自己 LLM 脚本叫一次 API,直接用 SDK + HTTP 比起 MCP server 快多了。
**自家产品内部 hot path。**MCP 多一个 process 边界跟协议开销。如果是你 SaaS 内部的 chat 调用自家 DB,直接调用更精简。
**不可信 server。**安装一个来路不明的 MCP server,等于给它 AI client 的工具权限。把 MCP server 当浏览器扩展来看 — 只装你信任的。

安全注意事项

几个真实风险:

恶意 MCP server 可能外泄 AI 看到的数据。
暴露一个名字看起来无害的工具的 server,可能诱导模型调用(跟 prompt injection 重叠)。
工具描述会进 prompt — server 描述如果是恶意的,可能改变模型行为。

大多数 MCP client 现在有权限 UI(「Allow Claude to use this tool: 是/否」),但协议本身不强制 sandboxing。对 MCP server 保持合理戒心。