MCP理解和实践 | 机核 GCORES

本文系用户投稿，不代表机核网观点

市面上大部分讲MCP的文章，基本都会出现下面这张图，也非常容易理解：MCP就是客户端（Client）和各种服务端（Server）之间为了更方便交互沟通，定义的标准协议。

但是这些文章大都浮于表面，自己一直比较好奇的两个问题得不到很好的解答：
为什么一个标准协议会这么火，背后有什么特别厉害的技术么
如果客户端接入的Servers越来越多，客户端集成的大模型怎么能正确知道用哪个Tool的（因为毕竟做了两年多大模型项目，对模型能力天花板还是有一定了解的）
于是自己读了源码和做了一些实操分析，在这里将结论分享给大家。
先说结论：的确只是一个标准协议，如果Servers太多大模型部分存在瓶颈。所以如果有想做MCP Client，不应该追求接入更多的Servers，而是追求价值更高并且交集更少的Servers。
下面将介绍3部分内容："Clinet是如何调用Servers"、"总结的优缺点和结论"以及"结论验证"
Client调用MCP Server的流程
官方介绍文档提到了调用流程：Claude是客户端，由客户端分析使用和决定使用哪个工具。

GitHub上MCP官方Client有个simple_chatbot的Demo，读了源码后整理了如下流程：
step1: Client首先收集所有MCP Server的Tools有哪些
step2: 这些Tools按一定格式整理成文本信息，包括：工具名、描述、参数以及参数是否必填
step3: 将第二步整理的工具文本信息拼接到system中
step4: 用户查询的问题作为user，和第三步的system一起传给客户端的大模型，让大模型选择Tool并且解析所使用Tool的具体参数
step5: 调用Server的exceute_tool函数，将第四步的解析结果作为函数的参数，得到工具返回值
step6: 再结合历史所有信息，再次调用大模型，得到最终结果 

不难看出，其中并没有新技术，如果Servers越来越多，特别是其中包含语义相近的工具时，卡点一定会出现在step3和step4这一步。
优缺点总结和结论
优势：「绿色」部分，众多Server的工具统一协议，方便客户端的大模型理解和调用，而不用针对每个工具自定义适配
缺点：「红色」部分，越多的工具导致：1）对工具描述精准度越高；2）对「红色」Promopt要求越高；3）对大模型能力要求越高。

结论：做MCP Client不应该追求接入更多的Servers，而是追求价值更高并且交集更少的Servers。
结论验证
选择免费的Cline和Anthropic的Claude做验证。
Cline - AI Autonomous Coding Agent for VS Code
安装一个叫Time的Server，包含两个工具：get_current_time 和 convert_time

截取的Prompt可以看到（截取方案可以参考附录链接）：
1、Prompt中按照一定格式拼接了工具信息

2、模型使用工具的Instruction都是通用的描述，如果直接泛化到企业内部必然需要额外的定制工作

Claude选择桌面客户端，因为它不能更换自定义模型，所以拦截不到Prompt，但是通过测试可以侧面验证。
我在Claude注册了4个Server，其中：
sqlite是官方发布的Server
SqlTemplateServer是我自己本地python写的一个Server

这两个Server存在有歧义的Tool：read_query 和 list_detail_tool 都和查询数据有关。

对“查询mid_tblogin表数据”这个问题，我的预期是使用list_detail_tool。可以看到Claude的Prompt很难做到准确判断，也就侧面验证了结论。

附录
如果想自己动手实践，建议调试simple_chatbot的源码，参考这篇文章
关于如何抓取Prompt，可以使用Cloudflare的AI Gateway，参考这个视频