MCP 是什么：给大模型"接工具"的通用协议

我对 Claude 说”看下我明天有什么安排”，它真的把日历里的日程一条条列了出来。第一次见到这个场景的人多半会愣一下：大模型不是只会生成文字吗，它怎么碰到我的日历的？

这背后就是 MCP——Model Context Protocol，模型上下文协议。今天把它讲成人话。

模型只点菜，不下厨

先拆掉一个误解：大模型从头到尾都没有”执行”任何东西。它没有手，只有嘴。

所谓调工具，是模型在对话里说出一句结构化的话：“我想调用 calendar.list 这个工具，参数是明天的日期。“真正去执行的，是包在模型外面的那层宿主程序——Claude 桌面版、Claude Code 这类应用。宿主拿着这句话去调真正的日历接口，把查到的结果塞回对话，模型再接着用人话组织答案。

整个过程里，模型只负责”点菜”，下厨的始终是宿主。这也顺带回答了安全问题：执行权在宿主手里，每一步要不要放行，最终由你说了算。

没有协议之前：M×N 份胶水代码

点菜机制不是 MCP 发明的，各家早就有”function calling”。真正的麻烦在别处：工具怎么描述自己、调用请求长什么样、结果怎么传回来——以前每家各搞一套。

于是 M 个 AI 应用想接 N 个工具，就得写 M×N 份胶水代码。日历接过 Claude 还得再为别的应用接一遍，谁都烦。

MCP 做的事情就是把这层”怎么对话”标准化。它是 Anthropic 在 2024 年底开源的协议，底层是 JSON-RPC：工具方把自己包装成一个 MCP server，AI 应用一侧实现 client，双方就能互认。M×N 从此变成 M+N——工具只需实现一次，就能被所有支持 MCP 的应用使用。

一个 MCP server 主要暴露三样东西：tools（模型可以请求执行的动作）、resources（可以读取的数据）、prompts（预置的提示模板）。宿主启动时先问一句”你都有什么本事”（tools/list），把工具清单放进模型的上下文；模型想用哪个，宿主就发一条 tools/call。

我写过一个最小的 MCP server

为了搞清楚这协议到底有多复杂，我自己动手写过一个最小实现：一个不依赖任何第三方库的 Python 脚本，从标准输入一行行读 JSON，实现 initialize、tools/list、tools/call 三个方法——总共百来行代码，就能被宿主接上，让模型调用里面的工具。

写完的感受是：协议本身简单得有点意外。它值钱的地方不在技术深度，而在”大家都认”。

认的效果是实实在在的。现在我给 AI 装一个新能力，不写任何代码：配置里加一行，接上现成的 server，下一轮对话模型就多了一双新的手。日历、数据库、剪贴板、浏览器，都是这么接上的。社区里现成的 server 已经多到挑不过来，OpenAI 和 Google 后来也相继宣布支持，MCP 基本成了事实标准。

当然，“装插件”式的便利也意味着信任问题跟着搬了家：接一个 server 就像给浏览器装扩展，来路不明的别乱接——它能干什么，清单里写得明明白白，装之前值得看一眼。

一点看法

常有人把 MCP 比作 AI 世界的 USB-C。我觉得这个比喻准的地方不在”接口通用”，而在后半段：接口统一之后，配件生态才开始爆发。协议本身不产生任何能力，但它让能力可以流通——给 AI 加本事，从一个开发行为变成了一个安装行为。这才是过去一年多 AI 应用突然变得”什么都能干”的真正原因。