站在2025年往回看MCPModel Context Protocol模型上下文协议已经不算新词了但它可能是过去两年里被误解最多、被滥用最多的技术概念之一。有人把它当成某种AI插件格式有人觉得它不过是OpenAI function calling换了个名字还有人因为配置一次Figma MCP失败就认定整套协议是智商税。这些看法的共性问题在于都是从“怎么用”出发而不是从“为什么需要它”出发。所以这篇我打算换个方式直接从MCP的第一性原理拆起——搞清楚工具调用是怎么一步一步长成能力协议的以及MCP到底在AI应用生态里承担什么样的生态位。理解到这一层后面那些“cursor怎么配mysql MCP”“codex怎么连figma”“到底是不是要自己写一个MCP server”之类的实操困惑基本上自己就能推理出来。1. 工具调用为什么最终会长成MCP这套协议要理解MCP先要回到一个非常原始的痛点大模型本身没有手它不能帮你查数据库、改文件、调用外部API。所以很早之前人们就开始给模型“装手”也就是工具调用function calling / tool use。这个思路本身不复杂把某个外部函数的名称、参数描述、功能说明告诉模型模型在推理过程中发现“我需要得到某个外部信息”于是输出一个结构化的调用请求再由应用层去真正执行这个请求把结果回传给它。早期这个模式很有效但它有个致命问题——每一套工具调用实现都只服务于一个特定模型和一个特定宿主应用。什么意思呢你在A平台上写好的一个工具列表换一个模型参数描述可能就得重写换一个宿主应用整个协议的传输方式、认证机制、错误处理又完全不同。这就让AI应用开发者陷入了一种“给每个模型定制专属工具链”的重复劳动里类似早年每家手机厂都有自己的充电接口明明底层需求一样但谁都不兼容谁。从第一性原理去看这里真正的问题不是“模型怎么调用函数”而是“能力供给方和AI消费方之间缺少一个统一的对接标准”。函数调用只是模型侧的一个机制它解决的是决策问题不解决分发和发现的问题。AI应用要接一个外部系统往往需要关注这个系统有哪些工具每个工具入参出参的schema是什么怎么调用调用是同步还是异步错误信息怎么返回更麻烦的是——如果这个能力是动态增长的今天有5个工具明天加了3个调用方怎么知道于是MCP从一开始就不是奔着替代function calling去的。它的目标是定义一套“AI应用host——MCP客户端——MCP服务器server——能力提供方”之间的通用话语体系把上面这些对接问题全部标准化。如果你是经历过Android没统一之前那种“每适配一台手机就要重写一遍底层驱动”时代的人你会对这个设计产生一种本能的熟悉感这不是某个功能的升级这是一次接口层的抽象。那为什么业界最终选择了MCP这套标准而不是别的这里有一个非常关键的推力大模型厂商发现如果每家都坚持用自己的function calling专用格式生态就没法形成规模效应。几乎所有主流模型服务商都在自己的协议之上接纳了MCP的接入方式包括各类集成开发环境、桌面端AI应用、甚至安全工具和逆向工程工具像是burp、x64dbg这些专业工具都开始提供MCP服务因为大家发现与其为每一个AI宿主各写一套定制插件不如自己实现一次MCP server的协议层然后全渠道复用。2. MCP和普通工具接口的本质差异从“单点调用”到“能力发现”很多人看MCP时只看到它底层也是JSON-RPC一种远程过程调用协议于是认为“这不就是另一种HTTP接口格式嘛”。这个判断说对了一半但丢掉的那一半恰恰是最核心的。一个普通REST API是“被动的”它规定好路径和参数只有别人按约定来调它它不会主动告诉别人自己有什么能力。而MCP server是“主动的”它通过协议内置的tools/list这类能力发现机制把自己的全部能力清单、参数描述、调用约束主动暴露给MCP客户端。也就是说AI应用接入一个MCP server之后不需要预先在代码里写死“这个系统有哪些函数”而是可以在运行时动态获取能力列表再交给模型决定调用哪个工具。这个差别就是“工具调用”和“能力协议”的分水岭。我再用一个更直白的类比解释这件事。普通函数调用像是你打电话给一家餐厅嘴上点什么对方做什么你事先得知道这家餐厅卖什么菜。而MCP更像走进一家餐厅先拿到一份菜单上面不仅有菜品名还标了配料、口味、辣度甚至标注了“今日售罄”的菜品然后你根据这份动态菜单来点菜。放到AI场景里“点菜”的不是用户而是大模型——它看到什么工具能用、参数是什么、现在是否可用然后做出判断。这种能力动态发现机制让AI应用具备了极强的可扩展性系统A哪怕今天新上了三个工具明天只要重启或刷新一下MCP连接宿主应用不需要修改任何代码就能感知到。而且MCP协议里能力单元不只是工具。它实际上设计了三个核心抽象Tools工具实现具体操作、Resources资源提供可读取的上下文数据、Prompts提示词模板把常见任务的触发方式标准化。很多人只盯着工具那一条完全没有意识到后面两者才是MCP区别于普通工具接口的关键设计——它定义的不是一条接口而是一整套“AI系统可以从外部获得哪些支持”的能力边界。Resources让模型能读取文档、图片、代码仓库这类数据资产Prompts让常见工作流可以像模板一样复用Tools才负责真正执行动作。这三类能力加在一起才称得上一个完整的“能力协议”而不是纯粹的“远程函数库”。还有一个不容忽略的设计点MCP从一开始就考虑了状态边界问题。每个MCP server在协议层是独立进程或独立服务它维护自己的会话状态而不是把状态塞进模型应用的主进程。你在浏览器自动化工具MCP比如Playwright MCP里打开了一个页面、登录了一个系统这个状态保留在MCP server这一侧主应用拿到的是结果而不是把整个浏览器状态耦合进宿主进程。这种隔离性在debug的时候价值极其明显——我的codex连接Figma MCP出问题时只需要单独观测MCP server的日志而不需要去翻AI宿主的一整堆应用日志。3. MCP与Skill、Computer Use、插件体系的边界在哪里社区里几乎每天都会看到“MCP和agent skill有什么区别”“MCP和computer use哪个更好”这类提问。之所以这么多人混淆是因为这些概念都在解决AI的“行动问题”但它们各自切的是完全不同的蛋糕搞清楚边界比记住定义重要得多。先说我个人最常被问到的一组MCP和agent skill。MCP解决的是“AI如何与外部系统对接”的规范化协议它高度依赖运行时连接适合接数据库、设计工具、浏览器、IDE、安全工具这类需要实时交互、数据结构往往有动态性的系统。而Skill通常指一组对Agent行为进行编排和引导的知识包——它会告诉Agent遇到什么任务应该调用哪些工具、用什么样的步骤策略、按什么质量标准交付。Skill是“大脑侧的行为策略”MCP是“手和眼睛接入外部世界的接口”。Claude的Agent Skills是很好的参照物一个Skill打包的往往是prompt、工作流脚本和参考文档它教模型“在这种任务里怎么干才靠谱”但它不负责实际发送HTTP请求或执行SQL。你在MCP生态里接到一个MySQL server它提供的是“查询某张表返回结果”的执行能力但不会告诉代码生成Agent“你应该先看表结构再写SQL”。而一个Skill做的事恰恰是定义这种“先看表结构、再生成SQL、然后通过MCP去执行”的推理顺序。这两者不是竞争关系是互补关系。你在Claude Code里配了MySQL的MCP server同时也写好一个“数据库操作Agent Skill”实际效果是Skill决定策略MCP负责执行。只有看到这一层协作的人才算是真正摸到了Agent工程化的门道。再说computer use。这个概念经常和MCP被放在一起提因为很多人的诉求都是“让AI能操作我的电脑”。但Computer Use本质上是一种执行方式它模拟人的视觉和鼠标键盘操作通过截图和坐标点击来控制GUI界面它的底层核心是视觉模型对屏幕元素的识别能力。而MCP是一种数据传输和指令协议它不需要“看”界面它直接以结构化数据或API命令的方式交互。如果目标是自动化一个GUI软件并且这个软件提供了命令行、脚本接口或开放APIMCP方案通常更稳定、更少误操作如果目标软件完全没有程序接口只能靠人去点鼠标那computer use路线几乎是唯一解。近年来也出现了把computer use能力封装成MCP server的实践——这是实现层的组合不是概念层的一致。插件体系和MCP之间的关系同样经常让人迷惑。传统意义上的插件比如VSCode插件、Figma插件通常是为特定宿主程序设计的扩展单元它跟宿主强绑定整个生命周期、UI渲染、权限模型都由宿主的插件规范约束。而MCP是一种跨宿主的能力供给标准同一个MCP server可以同时被Claude、Cursor、codex、各种支持MCP协议的客户端连接使用不需要分别开发不同的插件形态。用一句很直白的话总结插件是“给你的房子专门造的房间”MCP是“标准集装箱”凡是按这个标准制造的任何码头都能装卸。4. 真去用MCP时你需要关注的三层问题与排查路径MCP现在落地最频繁的场景是往Cursor、Claude Desktop、codex、VSCode这样的AI宿主里接各式各样的MCP server接MySQL查库、接Figma取设计稿、接Playwright做浏览器自动化、接burp和x64dbg做安全测试。关于这类实操网上教程铺天盖地但提问依然是最多的。因为绝大多数教程只写到“如何配置”而没有告诉你——当配置不生效的时候问题到底出在哪一层。根据我自己的调试经验MCP使用中的问题几乎都可以归入下面三层。第一层是配置层。这一层的错误最多也最不值得恐慌。以最常见的JSON配置结构为例MCP server一般分为两种拉取模式stdio型本地命令行启动和远程HTTP型URL访问。stdio型需要你准确写好command和args数组command必须是完整可执行的程序路径或在PATH里能找到的命令远程型则需要一个可访问的URL。很多人配置Figma MCP总是“工具注册不上”一大半情况是URL填错了、需要经过浏览器OAuth授权的URL没有先完成授权流程或者你用的是社区版但填了官方版的地址。我建议所有刚开始玩MCP的人先把你的配置对象单独打印出来一遍用一个最小化工具比如直接命令行执行那个server命令验证它能不能独立启动再谈后续。这能过滤掉至少一半问题。第二层是连接层。如果配置文件没有任何问题但宿主应用无法发现工具就要检查连接本身了。stdio型MCP常见坑是宿主的启动目录和server程序所在目录不一致导致相对路径对不上或者需要环境变量注入的运行时没有正确传参。远程型MCP这种情况更需要系统性排查server进程是否在监听防火墙有没有放行端口URL有没有带API token远程服务有没有要求设置请求头MCP本身并没有强行规定认证方式远程server的实现者可能用了API Key、OAuth或自定义Header的任意一种而客户端的配置语法往往因宿主而异。第三层是工具注册层。很多用户在宿主界面里看到了MCP server已经连接成功但模型就是“看不到”这些工具。这个问题的根子往往不是MCP连接而是宿主应用自身的上下文刷新机制。工具清单的加载时机通常发生在对话会话启动时或重启之后你运行到一半新加了一个MCP server当前会话并不会实时感知另一个常见原因是模型上下文窗口过大导致工具描述被截断或忽略一些实现较差的宿主在长上下文里甚至会降低工具注册的优先级。解决方案简单粗暴新建一个会话对话来测试或者把MCP server的总工具数量精简到模型实际需要的范围。为了更直观地看清排查路径我把我自己从“codex接Figma MCP失败”到最终跑通的完整链路写出来供参考先在codex CLI的配置里添加远程MCP server的URL重启codex会话输入指令要求查看当前可用的MCP工具这一步确认协议层是否连通返回“无法找到figma相关工具”提示我首先怀疑的是URL不可达直接通过curl命令请求server的健康检查接口发现远程服务返回正常继而怀疑认证未生效查看codex的日志输出发现请求远程MCP服务时并未携带token问题是认证上下文的配置字段写错了修正认证字段并重启会话再次检查工具列表工具注册成功。这个案例看起来不复杂但每一步如果没有“按层拆解”的思路很容易进死胡同。不看日志就反复改动配置是MCP使用中最消磨耐心的行为。所有debug的第一步永远是先确认协议层连通第二步才去考虑工具注册和模型决策层的问题。5. 需要自研MCP Server时的判断边界与最小实现思路社区里另一个高频问题就是我到底需不需要自己写一个MCP server还是直接用现成的就行这个问题没有标准答案但我可以提供一套足够清晰的判断框架。你至少要先想清楚一件事你的能力供给方是不是一个通用系统。如果你的目标是接MySQL、接Figma、接Playwright、接K8s、接github这些已经被社区实现过几百遍的通用系统那几乎不需要自己写server。去现成的server仓库里找一个兼容自己宿主的版本配好认证和权限就能很舒服地跑起来——写一个生产可用、边界处理完整、错误信息清晰的MCP server成本远比你想象的高。开源社区里那些被广泛使用的server例如各类官方维护的server仓库背后有持续迭代你自己维护一个的隐性成本非常可观。你可以评估需要自己动手的典型场景如下数据面完全私有比如你只能通过公司内网的内部平台API去取数外部没有现成MCP实现需要对AI工具的暴露范围做严格收缩不是这个平台的所有能力都要开放给模型而是只希望暴露少数几个白名单动作协议面特殊系统本身只维护在特定运行时中需要靠MCP server去做协议适配集成深度要求高不是一次调用就能完成的简单查询需要MCP server内部编排多个内部服务的结果。如果命中其中两条以上自己写一个MCP server是合理的。但请务必理解MCP server的价值不在于它用多高级的框架实现而在于它把“内部系统能力”翻译成了标准化的能力清单和调用语义。换句话说它是一个适配层不是一个业务系统。设计它的正确姿势是“想清楚暴露什么能力、用什么粒度暴露、什么数据可以给模型看”而不是先纠结用什么语言什么框架。官方提供的Python和TypeScript SDK软件开发工具包都是一线选择它们最大的用处不是帮你省几行协议代码而是帮你正确处理协议生命周期、错误返回和并发边界。如果你是要给逆向分析工具类做MCP对接更要注意处理执行时的超时和错误码映射。最小实现思路其实很短一个独立服务接收MCP协议标准的initialize请求然后实现tools/list和tools/call两个核心动作前者返回你的工具JSON schema列表后者根据调用参数路由到具体函数。至于Transport如果你主要服务本地AI宿主CLI、桌面端stdio模式就够如果你要供多台机器或多个宿主共用就主动升级成HTTP模式同时配置好鉴权。我用过不少生产场景下的部署方式这里分享一个做内部系统时的建议内部系统的MCP鉴权不要用自造的加密逻辑最简单的做法是在server侧强制要求一个固定的API Token在配置里以只读权限带进来就已经能挡住绝大多数误连和滥用同时做好服务的审计日志。MCP协议本身没有强制认证这意味着安全边界必须由你在实现server时自己负责不要等出了事故再补。6. 回到原则以“能力协议”的方式看待MCP而不是“工具文件”关于MCP的大多数困惑本质上都来自视角错位。如果你把它理解成“又一个工具配置格式”那确实很多东西看起来像是多余的抽象但如果你切换到能力协议的视角它会变得非常清晰MCP在制定一套让AI应用之间、AI应用与外部世界之间如何互相理解和协作的公共规则。这个规则天然要回答三个问题——能发现什么能力、如何调用能力、结果如何标准化返回。这个视角还会直接影响你的技术决策。比如你在Cursor里配MySQL MCP原生的需求可能是“帮我查数据”但只要用能力协议的方式观察一下MySQL官方server暴露的全部工具你马上会意识到模型真正需要的可能不只是执行查询而是先获取数据库Schema定义再决定查哪几张表。如果你选的MCP server只暴露了查询接口而没有暴露Schema读取接口Agent的工作效果就会大打折扣。同样道理给Figma配置MCP的时候最好的实践永远包含让模型能读取设计稿的图层结构资源而不只是开一个导出切图的工具了事。工具只是能力的载体真正起作用的是你如何理解和设计AI系统与外界系统之间的接口边界。最后说一点我自己的体会。很多时候我看到有人在一个MCP问题上反复纠结最后发现是对一些概念的理解错位了而不是技术做不到。所以我非常建议你在深入配置某一套MCP之前先坐下来用十分钟梳理清楚“我这个系统里谁是host谁是client谁是server、我接入它的目的是让模型拿到哪些能力、这些能力是tools还是resources”。想清楚这个比收藏十个配置教程都有用。MCP的复杂之处从来不在协议本身而在它连接的两侧——AI的决策语境和外部系统的真实约束。这恰恰也是这个领域到现在还很值得持续投入的原因它已经把工具调用往前推了一大步但离“能力自由组合”的最终形态我们才走完上半场。