过去一周，我研究了市面上的MCP项目，并且在mcp.so上阅读了300+的MCP Server。在经过多番代码的调试之后，我得到一个悲观的结论：
MCP是个残次协议
这是一个令人沮丧的结论，或许与你在各种公众号文章、短视频中听到的不一样，在我亲自上手之后，我发现，目前的MCP生态，虽然看上去一片繁荣，但是背地里却是一堆垃圾，各种大厂的跟进，像极了shit上雕花。我知道，写这样的文章会让有些人不快，甚至动了很多人的蛋糕。但是，当我发现事实真的很烂时，有些话不吐不快。接下来，我就来将我看到的事实，一一数落。
#1 MCP与大模型无关，起码目前是这样
没错，我认为这是MCP目前来讲，根上烂的问题。MCP究竟是什么？它的名字“Model Context Protocol”仅仅是沾上了“Model Context”的味道，但是跟大模型本质上没有一毛钱关系。这还要从MCP协议的流程来看。
MCP时序图
上图描述了MCP的工作流程，作为一项协议，其规定了很多内容，但总体而言，实际上就是对MCP Server的规定，其他的都是围绕MCP Server展开，例如MCP Client是利用这一协议，其他对象基本与协议无关。这里面存在的巨大问题是：Client应该如何把注册好的工具列表传给大模型让大模型给出调用名和参数。不同的客户端做法不同，例如Cline客户端是将工具列表塞入system_prompt，而其他不少工具只对接支持Function Call的大模型，把工具放在tools参数中交给大模型服务。两种做法各有优劣，Cline的做法灵活性强，即使deepseek-r1这样不支持Function Call的大模型也能被对接，劣势就是system_prompt体积巨大，credits遭不住消耗。反过来，基于Function Call的方案优劣势相反，而且输出结果格式更标准。
你可以在这里看到Cline的system_prompt。
但是，无论是哪一种方案，都是Client自己的方案选择，与MCP无关。对于基于Function Call方案的客户端们来说，没MCP之前和有MCP之后，没有任何差别。
那么，MCP究竟规定了哪一部分呢？看下图：
MCP的涉及范围
即MCP主要涉及了客户端如何注册和发现MCP工具，以及如何调用这些工具。
没错，你没有听错，起码就目前而言，MCP只是一个注册和调用的协议。而这个注册和调用的协议，本身与大模型无关，在脱离大模型的环境中，也可以存在。同时，从另外一个角度来说，MCP名字里透露的野心和真实场景中大模型开发的痛点，没有任何联系。
这是一个不争的事实：
MCP作为大模型上下文协议，却没有规定MCP客户端、服务端如何与大模型交互。
这就好像在说“我是一个针对食品安全的法律，但是我只要求食品原料产地符合标准，不约束食品生产厂商添加多少添加剂。”有一统江湖的野心，却只关注自家一亩三分地。
总言言之，就目前而言，MCP是一个工具注册与调用协议，没有解决大模型开发中与大模型交换工具参数（即以前Function Call）的痛点问题。这种挂羊头卖狗肉的现象，在美国创投圈普遍存在，玄妙的命名是创业者忽悠投资人的重磅武器。同时，国内自媒体圈把MCP吹上天，什么下一代人工智能“互联网协议”，替代智能体，等等言论，都是没有写代码去走通大模型连接MCP开发，听风就雨的胡扯。
#2 生态乱象，为发而发，80%无法使用，全是“傀儡SDK”
我在mcp.so上观察了300+ MCP Server的资料，MCP官方仓库列出了近千个项目，看上去生态繁荣，然而认真去读，我们就会发现，没有几个项目是有价值的。很多项目，仅仅是为了在名字上带上MCP字样，为了一点点流量，连readme都懒得好好写，就匆匆上线。
更有甚者，某些大厂为了争夺“xx第一接入MCP”的头衔，将毫无意义的几个工具整合一下，赶紧上线。于是，有了国内两家地图厂商同时成为“全行业第一家接入MCP的地图”的现象，然而去仔细看它们的项目，无非就是将原来的SDK做一层封装，发一个npm包，就抓紧上线，之后开始在公众号、小红书、抖音拼命投流。开发们快速涌入，定睛一看，首先要去他们的开发者平台申请一个Key，而申请Key需要做实名认证，另外还每天有一定限额。xx地图MCP Server，多高大上的名称，背地里无非是多了一个SDK分发渠道而已，但是汇报PPT里面却可以写上用户增长200%的显要成绩。
厂商们无非是多了一个SDK分发渠道而已
开发者们忍了，无非是后续超出限额后要收费而已，能用就行。真的能用吗？某度地图的MCP Server，工具不足20个，有5个要求传入经纬度，再来一个查天气要求传入行政区划ID却不告诉你这个ID怎么去取，真的是把开发者当傻子玩。无非是想让开发者回到它的开发者平台，把它的一整套生态都整明白。谁受的了。
类似的傀儡SDK，在mcp.so上数不胜数，国内的很多，国外的同样多的抠脚。
此外，还有很多MCP Server项目，完全不考虑开发者的实际运行环境，各种环境依赖，各种使用门槛，代码里面藏着缺失依赖，等等问题一大堆。就是像拼命发package一样，在MCP社区里也搞这种占坑行动。
我们对MCP生态的预期是什么？
是出现一些能够解决以前未能解决的问题。例如最近非常火的，通过大模型来操作浏览器，从而实现工作效率解放的场景。MCP社区出现了Puppeteer项目，以为可以经过一通折腾实现这样的处理逻辑，然而真正去接触的时候，真的是自己多想了，失望，充斥着每一次尝试。
在MCP社区，真正能无痛跑起来并对项目有帮助的Server屈指可数。
你可能说，“你看Cursor都接入MCP了，好多人都用上了，别人都能出成果，是你能力不行”。我不说话，Cline是开源的，阅读它的代码后才发现，所有的工具都是它预设好的，MCP工具可以忽略不计。
在我看来，MCP的出现，更像是Claude母公司Anthropic为了让其他开发者给自家产品赋能的噱头，这种为强势系统提供补丁的现象我见过，以前wordpress如日中天的时候，插件层出不穷，但好歹人家wordpress是开源的。如今把MCP吹上天的那帮人，让我觉得很恶心。
#3 为工具调用换个名词，对开发痛点没有帮助
作为开发者，非常希望基于大模型开发出有意思的项目。为了帮助用户实现某个目标，我们需要开发一个Agent来执行一系列任务。以“为我规划五一旅游出行”为主题的任务为例子，我们希望，让大模型结合MCP，可以做到对用户出行的线路、天气、饮食、住宿等做一份详尽的安排。然而实际上，MCP在此过程中的贡献，只有可怜的1%，开发者要解决：
- 用户需求的确认
- 任务设计与规划
- 工具的轮番调用
- 生成精美攻略
首先，用户的出行计划描述过于简单，是单人出行还是亲子全家游？是周边游还是其他目的的？是自驾还是其他交通？有没有饮食、住宿习惯？景点是想要人文的还是自然的？天气不好是否有影响等等。这些问题在开始做规划之前，都要和用户反复确认。但是大模型本质上是预测机，“反问用户”这个机制能力很弱，它宁可自己瞎胡诌，也不愿意与用户去确认。因此，这需要开发者做复杂的提示词工程和代码工程设计。
在拿到详细需求之后，在对旅游规划进行实施时，很多信息需要通过工具去获取，例如出行路线、天气情况、景点介绍等等。但是，就出行路线这个事，听上去简单对吧，从A市出发，到B市，帮我查一下出行线路规划。然而，你需要获取A B两市的经纬度坐标，还要提供各种信息。地图们上线的MCP Server，没打算做一个聪明的服务。
开发中，开发者们不仅要让Agent通过大模型作出规划布置，还不得不让大模型分析出每一步应该调用什么MCP工具去得到实时参数。形成一个调用列表，通过这些调用来获得实时信息。这个过程需要消耗大量的credits，而且有可能得到错误的参数，我们还要设计验证机制。
再接下来，开发者们需要基于上述逻辑，设计一套在适当的时机，调用对应MCP工具的流程。注意，在前面的时序图中，我们会发现一个非常大的漏洞，就是整个时序图是一次性的，而在实际开发中，我们需要轮番调用工具，调用A得到a，再把a作为参数调用B……这种情况，很有可能是MCP本身的问题，理想状态下，我们调用工具应该是以最小的参数得到准确的结果，然而现在的工具却基本不是这样设计，这些MCP Server工具看上去原子化，实际上就是懒得做聪明。
专注一次问答调用的设计，对整个规划毫无帮助
最后，当我们基于一整套工程，生成了一份攻略，需要生成一份精美的文档。按理来说，这下MCP应该可以帮大忙了吧，无非是把攻略内容传入一个MCP Server，然后拿到结果返回用户呗。可是，我们在MCP社区，找不到好用的工具。
让我们回顾上述这个任务的例子，MCP究竟帮助了开发者什么呢？既没有帮助我们提供非常好用的工具，也没有解决我们需要轮番调用工具的痛点。在没有MCP之前，开发者只需要在特定节点上暴力调工具，然后得到想要的结果即可。在有了MCP之后，开发者不得不折腾如何去适配MCP Server的调用。MCP除了在社区提供了一些不痛不痒的Server之外，几乎没有给开发者带来什么好处，反而为了适配MCP而花费大力气，结果下来发现满足不了需求之后还得同时保留以前暴力调工具的那一套，两套逻辑增加了复杂性。
MCP不仅没解决痛点问题，反而增加复杂性
总之，在我看来，以目前MCP的发展现状而已，真没到说“颠覆”“替代”的程度。提出一项协议容易，解决开发者的痛点难。理论上，当一项新技术出现时，可以帮我们解决问题，而不是制造麻烦。但是，我们如果把对MCP的预期，当作已经落地的现实，来吹捧其niup，真的是一种可耻。
结语
本文从3方面详细阐释了为什么MCP就目前而言，是非常鸡肋的，一方面它本质上没有提出客户端与大模型在工具上的交互标准，而是在外围搞了一个工具注册和调用的协议，通过取名学占据了市场高地；另一方面，它的社区生态不够健康，很多项目仅仅是为了趁热度发功能不健全的包；再一方面，在真正解决实际应用场景时，MCP带来的帮助几乎可以忽略不计，真正在应用开发领域需要被解决的问题，还得依靠开发者们的智慧，然而最终的成果却可能被MCP收割为成功案例。我们应该肯定开发者们在社区活跃的热情，然而，我认为，开发者们不应该一腔热血喂狗喷，以MCP社区目前的发展线路而言，如果没有一位强人强效的推进MCP到正确的道路上，那么不久的将来我们会抛弃它，如今投入大量的工作在上面，可能得不偿失。
2025-04-25 472
