聊一聊最近很火的MCP协议
写在前面
笔者最近在用Dify调用工具，但是发现效果非常不好，而且内部都是封装好的，不知道它是如何调用工具的。而现在公司恰好有些需求是要求让大模型直接调用本地文件，目前只能将文件上传上去，但是大模型的数据通常都是截止到某个时间点的，即训练的数据集始终是落后且固定的，无法实时获取数据。
当然我们可以使用联网搜索，也可以使用知识库，接口等方式将自己的数据上传给大模型，但是感觉使用起来还是差点意思，无法做到架构的统一化。鉴于此，MCP协议诞生了。
什么是MCP
MCP全称（Model Context Protocol），即模型上下文协议，是美国一家Ai初创公司Anthropic于2024年11月推出的一种开放协议，旨在标准化大模型（LLM）与外部数据源、工具的交互方式。Anthropic也是大语言模型Claude的母公司。
MCP的主要目的在于解决当前AI模型因数据孤岛限制而无法充分发挥潜力的难题，MCP可以使AI应用能够在安全控制下，访问及操作本地和远程数据，为AI应用提供了连接万物的接口。
即MCP可直接在AI与数据（包括本地数据和互联网数据）之间架起一座桥梁，通过MCP服务器和MCP客户端，开发者只需遵守这套协议，就能实现“万物互联”。有了MCP，可以和数据和文件系统、开发工具、Web和浏览器自动化、生产力和通信、各种社区生态能力全部集成，实现强大的协作工作能力，大模型+MCP+生态工具的价值将变得不可估量。
举个例子，现在有一个图书管理系统，当你使用MCP进行改造后，不论是ChatGPT还是Claude，都能使用同一套指令实现图书的增删改查，而不用为每个Ai单独开发对应的接口。
MCP与Function Calling的对比
我们知道，Function Calling是AI模型调用函数的机制，而MCP是一个标准协议，它使AI模型与API无缝交互。AI Agent是一个自主运行的智能系统，利用Function Callling和MCP来分析和执行任务，实现特定目标。
下面这张图便是MCP与Function Calling的对比：
数据安全
前MCP通过标准化的数据访问接口，减少了与数据直接接触，降低了数据泄露风险，使AI应用能够在安全控制下，访问及操作本地和远程数据，为AI应用提供了连接万物的接口。
实际上，MCP服务器内置了安全机制，确保只有经过验证的请求才能访问特定资源，相当于又加了一把安全锁。且MCP还支持多种加密算法，以确保数据在传输过程中的安全性。
MCP的核心原理
MCP协议采用了独特的架构设计，将大模型与资源之间的通信划分为三个部分，即客户端、服务端和资源端。
客户端负责将请求发送给MCP服务器，而服务器则将这些请求转发给对应的资源端。这种分层设计使得MCP协议能够很好的实现权限控制，确保只有经过授权的用户才能访问特定的资源。
MCP的基本工作流程
MCP的基本工作流程如下：
（1）初始化连接请求：客户端向服务器发送连接请求，建立通信通道；
（2）发送请求：客户端根据需求来构建请求信息，并发送给服务器；
（3）处理请求：服务器在接收到请求之后，解析请求内容，并执行对应的操作，如查询数据库，读取文件等；
（4）返回结果：服务器将处理结果封装为响应消息，发送给客户端；
（5）断开连接：任务完成后，客户端可以主动关闭连接或者等待服务器超时关闭。
上述流程对应的示意图如下：
MCP客户端工作流程
下面是MCP客户端的工作流程，如下所示：
（1）MCP客户端首先从MCP服务器获取可用的工具列表；
（2）将用户的查询连同工具描述，通过Function Calling一起发送给LLM大模型；
（3）LLM大模型根据需求来决定是否使用工具以及使用哪些工具；
（4）如果需要使用工具，MCP客户端会通过MCP服务器执行对应的工具调用；
（5）工具调用的结果会发送给LLM大模型；
（6）最后将响应展示给用户。
MCP服务器主要作用
下面是MCP服务器提供的主要作用，如下所示：
（1）资源：类似文件的数据，可被客户端读取，如API响应或者文件内容；
（2）工具：可以被LLM调用的函数，注意这些需要得到用户的准许；
（3）提示：预先编写的模板，以帮助用户完成特定的任务。
这些作用使得MCP服务器为Ai应用提供丰富的上下文信息和操作能力，从而增强LLM的实用性和灵活性。
小结
本篇我们学习了MCP以及其中的三个角色，包含客户端、服务端和资源端，对应的解释如下：
（1）客户端：可理解为是Ai应用层，如聊天对话框。用户输入信息后，由客户端接口接收，再由客户端调用服务端调配资源处理；
（2）服务端：可理解为注册中心，请注意所有的工具都是注册在服务端；
（3）资源端：资源端就是大模型解析之后的用户需求的服务，即实际的处理逻辑。资源端可以和服务端部署在一起，也可以单独部署。
