MCPModel Context Protocol这个词火了快一年但我发现大多数人的理解还停留在“AI 调用工具的统一格式”这个层面。这个理解不算错但很可惜它把 MCP 想小了。今天我想用第一性原理把 MCP 从工具调用重新拆一遍它真正改变的不是“函数怎么调”而是“能力怎么被声明、被发现、被组合”。这篇文章适合正在接 MCP 但总觉得哪里没想透的开发者也适合在 Cursor、Codex、Cline 里配了一堆 MCP Server 却搞不清它们之间关系的同学。看完你会明白为什么我把 MCP 称作能力协议而不是工具调用协议。1. 先别急着调工具MCP 解决的根本矛盾1.1 Function Calling 的“三堵墙”要理解 MCP 为什么会出现得先回到没有 MCP 的时候。大模型应用接入外部能力最原始的做法是 Function Calling也就是我们在系统提示词里塞一堆 JSON Schema告诉模型“你有个函数叫 search_docs参数是 keyword类型是 string”。模型根据这坨 schema 输出一个结构化的调用意图代码再去执行对应函数。这套机制今天依然大量存在OpenAI、Anthropic、Google 都有各自的 function calling 实现。但只要你做过三个以上的 AI 应用就会撞上三堵墙。第一堵墙是schema 与实现的双份维护。你写了一个 Python 函数get_user_orders(user_id)为了让它能被模型调用还得在另一个文件里手写一份对应的 JSON Schema描述参数、类型、必填项。函数改了schema 经常忘了同步。第二堵墙是静态上下文的容量瓶颈。所有工具描述都必须塞进 prompt工具一多几千 token 就没了。我见过有人往 system prompt 里塞 20 个工具的 schema结果模型开始“幻觉式调用”根本不存在的参数。第三堵墙最致命工具是宿主私有的换一个应用全部重来。你在 Web 应用里写好的工具函数换个 Chat 客户端、换个 IDE 插件一行都带不过去每个宿主都得自定义一套工具注册和调用协议。这三堵墙的本质是什么是工具调用这件事被绑定在了具体应用的实现里。模型和外部世界之间的接口本该是公共的、动态的、可以由多方共同维护的现实中却成了每个应用自己后院里的私房菜。1.2 MCP 出场把“我要调用”变成“你能提供什么”MCP 的切入点正好打在这三堵墙上。它的思路不是继续优化“function calling 的格式”而是引入了一个全新的中间层MCP Server 作为独立的能力提供者模型所在的 Host 作为能力消费者二者通过标准协议对话。这个变化看着只是加了个中间人但性质完全不同。在 function calling 的世界里模型应用是主体工具是被动等待调用的客体一切行为都围绕“我这个应用有什么函数”展开。在 MCP 的世界里模型应用不再需要提前知道一个函数的存在它只需要问一句“你MCP Server能提供什么”服务器回答“我提供这些 tools这些 resources这些 prompts。”然后模型再决定用哪个。这就是工具调用和能力协议的临界点。工具调用描述的是“我怎么执行一个既定动作”能力协议描述的是“我如何发现并协商一个能力”。前者是编死的后者是运行时动态发生的。MCP 的核心原语里专门设计了tools/list这看起来只是个枚举接口但它背后代表的是能力的自描述一个 MCP Server 可以在运行时告诉客户端它有什么能力客户端不需要事先硬编码更不需要把能力清单打包进提示词。这种“动态发现”机制才是“协议”和“格式”之间真正的分水岭。2. 第一性原理拆解MCP 是能力协议不是工具标准2.1 能力声明的本质从“写死函数”到“运行时协商”我们可以把 MCP 的第一性原理压缩成三句话外部世界的每一种可交互能力都可以抽象为统一的接口这种接口应该由能力的提供方自主声明而不是由消费方预先定义消费者通过标准协议在运行时发现、选择、调用能力。围绕这三句话MCP 设计了极简的三角色模型Host宿主也就是 Claude Desktop、Cursor、Codex 这类 AI 应用Client宿主内部与 server 建立连接、维护会话的组件Server能力提供方暴露工具、资源、提示词。Host 与 Server 之间走 JSON-RPC 2.0传输层默认支持 stdio 和 HTTPSSE新版本还加了 Streamable HTTP。这个架构你越看越像什么像 HTTP 协议本身浏览器Host不知道服务器Server上有什么资源但知道该用 GET、POST 去试探服务器用 200、404 这些状态码告诉浏览器结果。MCP 把同样的哲学搬到了 AI 与外部世界的交界处。这就是为什么我坚持认为 MCP 的核心贡献不在工具调用本身而在“能力协商”。所谓能力协商是一套完整的生命周期initialize建立会话协商协议版本和 capabilitiestools/list发现可调用的工具集合resources/list发现可读取的数据资源prompts/list发现可复用的提示模板tools/call、resources/read、prompts/get执行具体操作。大家可以对比一下 Computer Use 这类方案它走的是“像素级操作界面”的路线让 AI 直接看屏幕、点鼠标、敲键盘。MCP 走的是“语义级操作界面”让 AI 直接面对能力本身不需要理解 GUI。两者的哲学差异很明显Computer Use 是让 AI 适应人类的操作方式MCP 是让外部世界以 AI 最容易理解的方式暴露自己。哪个更适合自动化毫无疑问是后者因为语义接口减少了感知和动作之间的误差代价是需要有人先为系统写一层适配。2.2 三种原语资源、提示、工具一个都不能少很多人以为 MCP Server 就是“把函数暴露给 AI”只用了 Tool 这一种原语。但 MCP 的真正设计野心藏在它定义的三类原语里。工具Tools是最容易理解的对应可执行的函数通常有副作用比如“发送邮件”“创建订单”“读取数据库”由模型自主决定何时调用。资源Resources则是可读取的数据载体可以是文件内容、数据库查询结果、API 响应甚至是file://协议下的本地路径。资源的意义在于它让模型在调用工具之前可以先“读取上下文”。比如一个代码仓库的 MCP Server可以暴露repo://src/main.py这样的资源 URI模型先读代码再决定怎么改。提示词Prompts在中文社区里讨论得最少但它其实最妙。Prompt 在 MCP 里是“可复用的模板”由服务端维护。比如一个数据库 MCP Server 可以提供一个prompts/sql_review模板客户端请求这个 prompt得到的不是文本而是需要填入参数的消息结构。这相当于把提示工程从客户端挪到了服务端由最懂某个垂直领域的人去维护提示内容。为什么要有三种而不是一种回到第一性原理真实世界的“能力”不是只有动作还有数据输入和任务模板。如果只有工具模型每次操作前还得有人在提示词里手动注入背景资料那上下文窗口依然会被撑爆。有了资源和提示词数据加载和任务编排也被纳入了协议范围。你连接一个 Figma MCP它不仅给你get_file这种工具还能让你直接读取设计稿的节点树资源连接一个蓝湖 MCP它不只会“切图”还能把设计规范作为资源暴露给模型。三者合在一起才构成一个完整的“能力面”。2.3 为什么“能力协议”比“工具调用协议”更准确我给 MCP 的定义是它是一套让 AI 应用在运行时发现、协商并调用外部能力的开放协议能力可以是动作Tool可以是数据Resource也可以是任务模板Prompt。工具调用只是这套协议下的一种消息模式。这个区分不是文字游戏它决定了我们怎么设计 MCP Server。如果你把 MCP 理解成“工具调用格式”你就会照着 function calling 的思路把每个函数都塞成 tool然后发现很多场景特别别扭——比如你想给模型提供一份很大的配置文档它会变成get_config()工具你想让模型读取项目状态又得写另一个工具。但如果你把 MCP 理解成能力协议你会自然地想这个能力域里有哪些数据resource、有哪些动作tool、有哪些标准作业模板prompt然后按领域建模。两者的设计产出是完全不同的。还有一个更实际的原因工具调用是“宿主单方面定义的”能力协议是“双方协商的”。在多智能体场景里这一点越来越关键。一个 Agent 作为 Host 去连另一个 Agent 暴露的 MCP Server两者之间不是主从关系而是能力供需双方的关系。宿主可以决定“要不要用”服务器可以决定“给不给这个客户端用”。这种松耦合才是多智能体协作的基础。所以说 MCP 是多智能体世界里“通信与协作的基础设施”一点都不夸张。3. MCP 和那些容易混淆的概念Skill、Computer Use到底差了些什么3.1 MCP 是管道Skill 是内容我在社区里经常被问到一个问题Agent Skill 和 MCP 有什么区别这俩概念确实容易混因为很多 MCP Server 装完之后效果看起来就是一个“让 AI 获得某项技能”。我的区分方式很简单Skill 是模型侧的“怎么想”MCP 是外部侧的“怎么连”。Skill 通常是一段提示词、一份 Few-Shot 示例、一套推理路径组成的“软技能包”它改变的是模型的行为方式不涉及外部系统交互。比如你给 Agent 装一个“代码审查 Skill”它学到的是审查的顺序、关注点、输出格式整个过程可以完全不碰任何外部 API。MCP 则解决的是“外部系统怎么把能力暴露给模型”的问题它需要实实在在的进程、服务、鉴权、数据传输。更直接地说Skill 是给 Agent 的大脑装软件MCP 是给 Agent 接五官和手脚。一个 Agent 可以只靠 Skill 完成纯推理任务但只要涉及读数据库、操作 Figma、调浏览器就必然要 MCP 这类通道。这里不存在谁取代谁的问题最佳实践恰恰是组合用 Skill 定义领域内的作业方法论用 MCP 打通所需的外部工具两者一个向内、一个向外。3.2 MCP 与 Function Calling / Tool Use 的继承关系那 MCP 跟 Function Calling 的关系呢我倾向于描述成“继承并超越”。MCP 的工具调用动作本质上是 function calling 的标准化网络版。function calling 解决的是“模型怎么表达调用意图”把 JSON Schema 塞给模型让它输出一段结构化调用。MCP 保留了这套交互模式但把工具的声明、注册、发现、执行、错误处理全部协议化并且从单机进程扩展到跨应用的网络边界。具体到工程上最直观的区别是function calling 的工具列表跟着应用走应用启动时注册应用死了就没了MCP 的工具列表跟着 Server 走Server 是独立进程开发完可以给任何支持 MCP 的客户端复用。换句话说function calling 是“一个应用私有的工具系统”MCP 是“一套跨应用公共的能力市场”。你在 Cursor 里配好了一个 MySQL MCP换到 Codex、Cline、Cherry Studio只要配置文件拷过去、依赖装好同样的工具马上能用不需要为每个客户端重新实现一遍工具注册逻辑。当然MCP 目前没有完全干掉 function calling。很多 Host 内部依然保留了自己的 function calling 层MCP 客户端拿到工具列表之后会把它们翻译成宿主内部能理解的 schema 再交给模型。但这层翻译是内部的对用户透明。对开发者来说你只需要写一次 MCP Server就能辐射到所有主流客户端——这是 function calling 时代无法想象的复用效率。3.3 MCP 与 Computer Use语义操作与界面操作的路线之争Computer Use 是最近很火的方向OpenAI 的 Computer Use、Anthropic 的 Computer Use 都是让模型像人一样操作屏幕。很多人对比 Computer Use 和 MCP结论是“Computer Use 让 AI 看屏幕点鼠标MCP 让 AI 直接调 API”这个总结大方向没问题但值得再往深挖一层。Computer Use 实际上是在模拟人的感知-决策-行动回路适用于没有 API、没有代码接入权限的遗留系统比如老旧的 ERP、桌面客户端。它的优势是普适什么系统都能操作劣势是慢、贵、误操作率高每次点击都需要视觉截图、坐标推算一次误点可能带来灾难性后果。MCP 走的是相反的路要求系统主动暴露自身能力以结构化接口呈现给 AI。它不是让 AI 适应一个“人看的界面”而是让人以外的世界适应 AI 的处理方式。这两种路线不是替代关系而是互补关系。接口完善的新系统优先上 MCP因为效率高、可靠实在没有接口的老系统再考虑 Computer Use 兜底。我见过一个比较成熟的架构是“MCP 为主Computer Use 兜底”优先让 AI 尝试通过 MCP Server 完成操作如果某个环节没有现成接口再动态唤起一个 Computer Use 的 Agent 去处理这块界面操作。这个思路我觉得在未来很长一段时间都是主流。4. 自己动手从零搭一个能“发现能力”的 MCP Server4.1 从零到一先选 SDK再谈设计理论讲再多不如亲手搭一个。做 MCP Server 有两种方式直接用官方 SDK或者裸写 JSON-RPC 协议。除非你想深入协议细节否则我都建议用 SDK。官方提供了 Python SDK 和 TypeScript SDKPython 的FastMCP封装得非常舒服代码量少适合快速验证TypeScript SDK 在前端团队里更顺。我个人日常验证想法用 Python因为代码最短。先说一个反面经验不要一开始就陷入“我要不要自己实现 MCP Server”的纠结。现在主流能力的 MCP Server 基本都有现成的蓝湖、Figma、MySQL、Playwright 全都有官方或社区版本。你需要自己实现 MCP Server 的场景只有三类内部系统没有现成接入、需要把多个内部 API 聚合成一个统一能力面、或者要对敏感数据做访问控制。其余时候优先复用成熟的 Server把精力花在能力编排上这才是杠杆率最高的做法。装好依赖后MCP Server 的最小骨架长这样pip install mcp[cli]用 FastMCP 实现一个最简单的工具from mcp.server.fastmcp import FastMCP mcp FastMCP(demo-server) mcp.tool() def add(a: int, b: int) - int: 计算两个整数之和 return a b if __name__ __main__: mcp.run()运行之后这个 Server 就监听在 stdio 上任何 MCP 客户端都可以通过标准输入输出和它通信。这段代码少得让人怀疑但它已经完成了 MCP 协议中最关键的几个动作定义了能力add 工具、暴露了描述docstring 会被自动转成工具描述、等待宿主发现通过 stdio 通信。4.2 再加点能力用 Resource 和 Prompt 构建“能力面”只写一个 Tool 不足以展示 MCP 的完整设计我通常会在 Demo 里把三类原语都放进去。下面这个示例模拟一个“项目知识库 MCP”既有查询工具也有可供读取的文档资源还有内置的分析提示模板。from mcp.server.fastmcp import FastMCP mcp FastMCP(project-knowledge) DOCS { 架构文档: 本项目采用前后端分离架构前端 React后端 Python FastAPI..., 接口文档: POST /api/v1/orders 用于创建订单请求体包含 user_id..., } mcp.tool() def search_docs(keyword: str) - list[str]: 根据关键词检索项目文档标题返回匹配的文档名列表 return [title for title, content in DOCS.items() if keyword in content] mcp.resource(docs://{doc_name}) def get_doc(doc_name: str) - str: 读取指定文档的完整内容 return DOCS.get(doc_name, 未找到该文档) mcp.prompt() def doc_analysis(doc_name: str) - str: 要求模型对某份文档做结构化摘要 return f请阅读文档《{doc_name}》从架构合理性、潜在风险、改进建议三个维度给出分析这个 Server 的形态大家体会一下Toolsearch_docs让模型可以搜索Resourcedocs://{doc_name}让模型可以直接获取文档原文Promptdoc_analysis让模型知道“拿到文档之后该怎么分析”。能力在这里不再是孤立的函数而是一个有上下文、有方法论的完整体系。如果只在 Tools 层面做文章模型往往不知道该读哪份文档也不知道读完之后该做什么。有了 Resource 和 Prompt宿主可以先把检索到的文档作为上下文读进窗口再套上分析模板最终产出结构化分析。整个过程没有人为写死任何一步全靠模型在运行时根据能力声明做决策。这就是“能力协议”在实操中的意义你给的不是一个函数而是一整套可以被自主调用的能力。4.3 把 Server 接进 Codex、Cursor、Cline配置一次到处复用Server 写完接进客户端才是最爽的时刻。拿本地 stdio Server 来讲主流客户端都会提供 MCP 配置文件入口形式大同小异。以 Claude Desktop 和 Cursor 的通用配置为例你需要在一个 JSON 文件里声明 server 名、启动命令和参数{ mcpServers: { project-knowledge: { command: python, args: [/path/to/project_knowledge_server.py], env: {} } } }Cursor 里是在Settings - MCP里添加底层会生成同样的配置。Codex CLI 则支持通过命令直接添加codex mcp add project-knowledge -- python /path/to/project_knowledge_server.pyClineVS Code 插件则在插件设置里有 MCP 配置面板填写 server 名、命令、参数即可。配置完重载之后你会在客户端的工具列表里看到project-knowledge前缀的工具。此时你就可以在对话里直接说“帮我搜一下接口文档里关于订单的内容然后用文档分析模板做一份评估”模型会自己决定先调search_docs还是直接读资源。这里有个需要提醒的点MCP Server 配置必须保证客户端进程能访问到命令和环境。比如 Codex 跑在 WSL2 里你装了某个数据库 MCP客户端在 Windows 侧而 Server 在 Linux 侧stdio 进程起不来工具自然注册不上。遇到这种情况先确认客户端本身就跑在 WSL2 里再检查 Python/Node 路径多数问题都出在执行环境不一致而不是 MCP 协议本身。4.4 垂直场景举例不止是代码和数据库MCP 的应用范围早就超出了代码领域。热词里最常出现的几类我说一下自己的实际观察设计协作Figma MCP、蓝湖 MCP 在国内外设计团队里铺得很快典型用法是自然语言生成 JS/TS 代码时模型先从设计稿读取样式和结构再生成对应前端代码游戏引擎Unity MCP、CocosCreator MCP 把场景树、资源列表、组件属性暴露给 AI模型可以直接说“在场景里创建一个带刚体的立方体并挂上材质”引擎侧自动执行安全分析BurpSuite MCP、x64dbg MCP、wazuh MCP 这类工具把原本需要鼠标点击的安全检测和调试动作协议化AI 可以自动完成请求分析、寄存器查看、告警聚合这类应用对稳定性和权限控制要求更高数据与科学计算MySQL MCP、MATLAB MCP 是老牌工具接入 AI 的样板数据库 Schema 作为 Resource、增删改查作为 Tool分析师可以用自然语言完成取数、建模、可视化。每个垂直领域接入 MCP 时都会面临领域特有的问题比如 Unity MCP 要处理引擎主线程的调度MATLAB MCP 要处理计算任务的同步阻塞安全类 MCP 要严格限制 AI 的自动化权限边界。但共性是一致的先把领域能力建模成 Tool、Resource、Prompt 三类原语再接进宿主让 AI 在协议框架内自主完成任务。5. 我在实战中踩过的坑和排查方法5.1 工具注册不上的常见原因很多人在 Codex 里配 Figma MCP工具总是注册不上。我排查过不少类似问题几乎都逃不出三个原因第一Server 进程根本没起来。stdio 类型的 Server 是由客户端负责拉起的如果你的 Python 或 Node 环境路径不对或者依赖没装子进程会静默失败。先手动在终端跑一遍启动命令确认没有报错。第二网络型 MCP 的鉴权失败。Figma 的社区 MCP 需要 Personal Access Token 或者 OAuthtoken 没有正确配置Server 即使起来了也无法通过 Figma API 的验证工具列表就拉不回来。解决方法是先确认 token 权限范围包含File content的读取权限再检查 Server 日志。第三Client 和 Server 协议版本不兼容。MCP 还处于快速迭代期SDK 版本和客户端支持的版本偶有不匹配表现为握手失败通常升级双方版本就能解决。这里给一个排查口诀先是环境命令能不能跑再是鉴权token 有没有权限最后才是协议SDK 版本对不对。按这个顺序查90% 的问题能自己解决。5.2 工具调用超时和上下文溢出工具挂上了实际调用时也会出问题我自己遇到最多的是两类一类是长耗时工具的调用超时。比如让 MCP 去跑一个复杂的 MATLAB 计算或者等一个数据库大查询模型这一侧的 HTTP 请求可能已经超时了。解决办法是把长任务改造成异步模式Tool 先返回“任务已提交任务 ID 为 xxx”再暴露一个query_task_status(task_id)的工具让模型轮询。这本质上是把同步阻塞调用变成异步任务队列在 MCP 场景里尤其重要因为模型对超时非常敏感等太久它会“自说自话”地编一个结果。另一类是大资源内容把上下文撑爆。resources/read返回一个几十 MB 的日志文件Token 会瞬间爆炸。这里需要在 Server 侧做内容裁剪或分页让资源按块返回或者先提供摘要工具。我自己的习惯是凡是要往上下文里塞的内容Server 一律先做截断或摘要只返回最关键的部分模型需要更多细节时再通过工具按需获取。5.3 Server 不是越多越好这是我最想提醒新手的一点。很多人看到 MCP 生态丰富就一口气装了十几个 Server结果对话时工具列表几十上百个模型每次决策都要在这堆工具里做选择既费 Token 又容易选错。而且不同 Server 之间工具同名冲突、权限边界模糊这些问题都会被放大。我的经验是单个对话会话内保持 3-5 个 MCP Server 是体验较好的区间。Cursor、Codex 这类开发场景通常一个代码库 MCP、一个数据库 MCP、一个设计稿 MCP 就足够了。需要更多 Server 的时候可以按项目拆分配置文件不同项目各自只挂相关的 Server。MCP 的配置文件写清楚之后这些都是低成本操作没必要让所有 Server 常驻。还有一个容易忽略的点MCP Server 的权限问题。MCP 是一个强大的通道但通道本身没有内置完整的权限审计。一个能操作数据库的 MCP宿主的提示词注入攻击一旦得手可能导致数据被删改。所以在设计内部 MCP Server 时一定要做好三个动作最小权限原则Tool 只暴露必需操作、操作审计记录每次工具调用、敏感操作二次确认比如删除类操作要求模型先调用一个“确认”工具。这些细节文档里不会写但生产环境里都是保命用的。6. 关于 MCP 未来的几点个人判断回到文章开头的问题MCP 到底是什么我再重复一遍我的结论它是一套能力协议不是工具调用格式。工具调用只回答“怎么执行”能力协议回答的是“能力如何被声明、发现、组合、复用”。理解了这一点你再看 MCP 生态里的各种进展就会有一个清晰的判断框架。在协议层面MCP 未来一定会补上两件事一是能力编排与会话状态的标准现在一个 Agent 跨多个 MCP Server 协调任务时会话状态分散在各 Server 里缺少统一的上下文协议二是安全与治理机制当前的服务发现、鉴权、审计都还比较原始企业落地时基本都要自己再做一层。这两块补上之前MCP 更适合“单 Agent 多工具”的架构大规模多智能体写作还早了点。在生态层面我比较看好两类 MCP Server 的沉淀一类是垂直领域的高质量能力面比如把 Figma、蓝湖的设计能力完整建模的 Server这类需要领域知识深度构建门槛高价值也高另一类是企业内部的“系统连接器”把内部 OA、CRM、数据库统一暴露成 MCP让员工通过 AI 助理安全地操作这类更考验权限设计和合规治理。最后再分享一个实操层面建议不要急着把现有 AI 应用的 function calling 全部改造成 MCP。把“必须跨应用复用”的能力抽取成 MCP Server把“只有一个应用内部使用”的工具继续保留在 function calling两条腿走路。我见过不少团队雄心勃勃地搞“全量 MCP 化”结果光迁移成本就吃掉了收益。MCP 的价值在于让能力流动起来如果能力本身不需要流动别为了架构的纯洁性引入不必要的复杂度。这一个取舍原则比 MCP 本身的任何技术细节都更重要。