MCP(Model Context Protocol) - 模型上下文协议

MCP(Model Context Protocol) - 模型上下文协议

它与前面的Tool Calling - 工具调用 类似，可以看作是 获取通用实时性能的 Function Calling工具调用 的增强，几乎可以完全取代Tool Calling，但Tool Calling并不是一无是处，最经典的：如果此工具类是小范围的一个或者两个服务用，即少的自己用就好，不需要把它提升到全局通用的层面上。

1. 为什么会有MCP，之前的痛点是什么？

上一节ToolCalling - 工具调用讲过，大模型有一个预训练的知识截止日期，“你是谁，现在几点了”：他可以知道自己是谁 - 我是deepseek，但现在几点了 - 对于这样的实时数据，大模型它是无法知道的；
在上一节ToolCalling - 工具调用已经解决过这样的问题，为什么还要MCP？：
SpringAI框架在1.0.0-M6时Tool Calling(即Function Calling)有一段时间被Deprecated弃用了，希望用MCP提到Function Calling，但是在SpringAI 1.0.0-M6以后，又拿回来采用了；
为什么会有这样的犹豫，推荐用MCP取代Function Calling？：
如果有这样的犹豫，证明Function Calling能做的MCP也能做，它不能做的MCP也能做，所以可以理解MCP是下一代的Tool Calling；
用Tool Calling解决无法获取实时数据有哪些痛点？：
之前每个大模型(DeelSeek、ChatGPT)需要为每个工具单独开发接口(FunctionCalling)，导致重复劳力；有两个痛点：共用和数量
1️⃣共用：上节ToolCalling中 DateTimeTools.java 工具类可解决获取实时数据的能力；当问大模型实时相关的问题，大模型说了搞不定当前时间实时数据，于是写了此工具类解决问题；但其他微服务也需要实时数据时，每个人都要写一个；那就需要把此工具类提取出来成为一个公用的。
2️⃣假设一个工具只能做一件事，现在有三个需求：获取当前时间、获取当前天气、获取股票实时信息，此时就要写3个工具类，那么工具类就会越来越多；
那如何兼顾 共用➕数量 问题？
即多个微服务(java微服务➕LLM)都需要去调用多个实时数据(如时间、天气、股票)，就需要一个公用的服务，假设它也是一个大模型LLM；那么：两个模型(LLM)之间的调用应该遵守什么协议？
对于数量：假设需要三件事如时间、天气、股票，LLM里面 提供一个服务：百度地图MCP，里面有1.路线规划，2.当前时间，3.交通拥堵，4.坐标经纬度定位，5.天气预报；即 只要是共用，每一份(java微服务➕LLM)不要独享，提出来一个共用的LLM，类似SpringCloud Alibaba的Nacos服务注册中心，大家都去找同一个，且它在功能上要求较多即需要多个数量；即不仅公用还要兼顾数量，此时就可以升个级，把它也变成一个大模型服务，那么就变成模型调模型，模型之间应该遵守什么协议？即模型上下文协议MCP。

2. MCP的入门概念

1️⃣MCP自身协议官网：https://modelcontextprotocol.io/docs/getting-started/intro
2️⃣SpringAI官网支持MCP：https://docs.spring.io/spring-ai/reference/api/mcp/mcp-overview.html
3️⃣SpringAI Alibaba官网支持MCP：https://java2ai.com/docs/1.0.0.2/tutorials/basics/model-context-protocol/?spm=5176.29160081.0.0.2856aa5ccBJ7XE

4️⃣是什么？
Java界的SpringCloud OpenFeign，只不过OpenFeign是用于微服务通讯的，而MCP是用于大模型通讯的，但它们都是为了通讯获取某项数据的一种机制。
5️⃣能干嘛？
提供了一种标准化的方式来连接LLMs需要的上下文，MCP就类似于一个Agent时代的Type-C协议，希望能将不同来源的数据、工具、服务统一起来供大模型使用。
图一：

图二：

将上图原本一对一的变成下图：模型调模型，大模型之间沟通都用MCP，MCP clients通过中间MCP服务协议找到各种各样的大模型MCP server。

调用中间MCP服务器(红色)相当于调一个utils工具类，里面有四个小方法(蓝色应用示例)，全封装在红色部分，对外暴露为一个MCP供大家调用，通过MCP协议找到红色部分即可调用里面的各个方法。
6️⃣怎么玩？
提供上万个通用MCP供调用，类似于MCP的git hub，全球通用：https://mcp.so/zh

3. MCP架构知识

1️⃣MCP遵循客户端-服务器架构(CS服务架构)，它包含了以下几个核心部分：

主机是MCP Client，它要通过MCP协议去调用MCP Server A、B、C(比如上方MCP github中的任意MCP服务：Redis、Time、高德地图Amap Maps等)，本地idea中起了一个微服务，这个微服务整合了大模型alibaba通义千问，此时通义千问就想去调用Redis、Time、地图等；MCP Server A、B这两个微服务又去调用自己的本地数据源，MCP Server C这个微服务又去调用外部第三方的（如高德地图又去调用天气）另外的远程服务；
MCP主机（MCP Hosts）：发起请求的AI应用程序，比如聊天机器人、AI驱动的IDE等；
MCP客户端（MCP Clients）：在主机程序内部，与MCP服务器保持1:1的连接；
MCP服务器（MCP Servers）：为MCP客户端提供上下文、工具和提示信息；
本地资源（Local Resources）：本地计算机中可供MCP服务器安全访问的资源，如文件、数据库；
远程资源（Remote Resources）：MCP服务器可以连接到的远程资源，如通过API提供的数据。

2️⃣在MCP通信协议中，一般有两种模式：
STDIO（标准输入输出）：支持标准输入和输出流进行通信，主要用于本地集成、命令行工具等场景；
SSE（Server-Sent Events）：支持使用HTTP Post请求进行服务器到客户端流式处理，已实现客户端到服务器的单向通信；


两者对比： 两者用谁都行，但一般用STDIO，因为一般调用一个服务双向流用的较多；