图解 MCP

0 阅读16分钟

MCP (Model Context Protocol) 是由 Anthropic 提出的一种协议,用于规范 AI 模型与外部系统之间的交互。它定义了一套标准化的接口和数据结构,使得 AI 模型能够以更可预测和可控的方式与外部系统进行交互,从而提高系统的可靠性和可维护性。 这几个月以来,MCP 的发展可谓是迅猛,其技术迭代、生态扩展和行业渗透均取得显著突破。

MCP 架构

根据 Anthropic 的官方介绍,MCP 采用客户端-服务器架构,允许主程序(Host)连接多个服务器:

核心组件:

  • 主机(MCP Hosts): 需要访问数据的程序,例如 Claude 桌面客户端、IDE(Cursor, VSCode Cline 等)或其他 AI 工具(Cherry Studio 等)。
  • 客户端(MCP Clients): 协议客户端,每个客户端与单个 MCP 服务器保持 一对一连接
  • 服务器(MCP Servers): 轻量级程序,通过标准化的 模型上下文协议(Model Context Protocol) 暴露特定功能。
  • 数据源(Local Data Sources): 计算机本地的文件、数据库或服务,MCP 服务器可安全访问。
  • 远程服务(Remote Services): 通过互联网连接的第三方系统(例如 API),MCP 服务器可对接调用。

MCP 使用

Cherry Studio

Cherry Studio 为例,最简单的配置方式是通过同步 魔搭社区 MCP 市场 hosted 的一些 MCP 工具:

也可以手动添加 MCP Server:

MCP Server 有三种传输类型:

特性维度Stdio(标准输入输出)SSE(Server-Sent Events)Streamable HTTP
通信协议系统级标准输入/输出流基于 HTTP 的单向事件流(text/event-stream)基于 HTTP 的双向分块传输(Chunked Transfer Encoding)
通信方向双向同步(请求-响应模式)单向(仅服务端 → 客户端)双向异步(支持客户端与服务端的流式交互)
协议层级操作系统进程间通信(IPC)应用层 HTTP 协议扩展应用层 HTTP/1.1 或 HTTP/2 原生实现
实时性低延迟(100-500 μ s)中延迟(50-200ms)高实时性(10-100ms),支持按需流式响应
连接模式短连接(进程生命周期绑定)长连接(需持续维护)动态连接(可持久化或按需建立)

  • 运行在本地的 MCP Server 通常使用 Stdio ,客户端以子进程形式启动服务端,通过 stdin/stdout 交换 JSON-RPC 消息,消息以换行符分隔
    • 通常需要 node.js 的 npx,或者 python 的 uv,或者 docker 环境
  • 运行在远端的 MCP Server (比如上面魔搭社区托管的服务)通常使用 SSE(大部分 Server 采用的方式),Streamable HTTP(最新的方式,适配的 Server 还不多),通过 http 请求 JSON-RPC。

配置好 Server 后,可以在每个 Server 的 工具 栏看到所有可用的工具的描述和输入要求:

回到对话时记得选择上 MCP Server:

如果模型判断需要调用 MCP 工具,就可以看到工具调用的标识:

VSCode Cline

再来看看 VSCode Cline 插件,可以在 Marketplace 一栏直接让 Cline 帮忙安装:

Cline 偶尔会安装失败,建议根据 MCP 文档,手动配置,在 Installed 一栏选择 Configure MCP Servers,会打开一个 JSON 文本,直接写配置:

安装完成后,可以在 Installed 一栏看到 MCP 的介绍:

回到对话进行询问:

搭建一个 MCP Server

下文所用的代码均在 mcp-server

上文简单介绍了如何配置和使用 MCP 服务,但是 MCP 究竟是如何工作的呢?配合 官方文档,以及官方提供的 typescript-sdk,我们来搭建一个最简单的 MCP Server(当然,你也可以鞭打 AI 来帮忙完成这项工作)。

该 Server 主要提供了三个工具:

  • 两数相加工具
  • 三数相加工具
  • 获取当前时间工具

接下来,可以通过 @modelcontextprotocol/inspector 来调试:

启动成功后,我们打开 http://127.0.0.1:6274 就能看到调试页面:

  • 左侧是连接信息,由于我们只开发了 Stdio 传输类型,直接连接即可
  • 连接后,会在 Tools 一栏显示所有的工具信息,选择某一个工具后可以直接输入测试
  • 下方则是 MCP Client(网页) 和 MCP Server 之间的通信历史

如果要支持 SSE/Streamable HTTP,可以在之前代码的基础上添加以下代码:

  • SSE: 通过 /sse 进行通信
  • Streamable HTTP:通过 /mcp 进行通信

Client、Server Lifecycle

  1. 建立连接阶段(蓝色背景)
    • 三次握手过程:能力协商(initialize request) → 确认(initialize response)→ 就绪通知(initialized)
    • 必须完成才能进入正常通信
  2. 消息交换阶段(绿色背景)
    • 支持两种模式:
      • 带 messageId 的请求-响应(严格匹配)
      • 无 messageId 的通知(单向消息)
  3. 终止阶段(红色背景)
    • 两种终止方式:
      • 显式关闭协议(clean shutdown)
      • 传输层意外断开

MCP 协议规定 Client 和 Server 之间的通信数据基于 JSON-RPC 2.0 规范,具体协议规范见 Specification。MCP 官方提供的 SDK 则是对这些规范进行了封装,我们只需要调用其提供的一些工具方法,就能完成符合规范的 MCP Server 或者 MCP Client。当然,我们也可以从 0 搭一套,只要对齐规范就行。

除了 Tools 外,MCP 还规定了其他的一些资源规范,比如 Resources, Prompts 等等。不过目前 MCP Host 所使用的 Client 对其他资源的支持还不太好,所以不做重点介绍,可以通过 feature-support-matrix 了解详情。

至此,这就是 MCP 的关键。

等等,那这和大模型有什么关系?

MCP 里面的 Model 听起来挺唬人的,但实际上 MCP 和模型本身没有任何关系,它只是规范了 MCP Client 和 MCP Server 之间的通信,规范了服务连接、工具发现、工具调用等链路。我们可以使用任何符合规范的方式连接 MCP Server 或 Client,然后以规范的格式进行通信

统一规范这件事并不稀奇,比如 VSCode debugger adapter:

再或者是 LSP(Language server protocol):

MCP Host(LLM 如何使用工具)

在实际开发过程中,我们并不会直接使用 MCP Client,更多的是使用 MCP Host,比如我们上文提到的 Cherry Studio 或者 Cline。它们内部一方面负责和 LLM 通信,一方面使用内置的 MCP Client 和 Server 进行通信。那 LLM 到底是如何使用工具的呢?Host 是如何把两者组合起来的呢?

通信捕获

抓包

我们使用 Charles 来抓包,获取 MCP Host 和 LLM 之间的通信。在 Cherry Studio 中,我们选择 Deepseek 模型来提问:

在 Charles 中过滤 Deepseek 的请求,可以看到 Charles 捕获到两条请求:

在 Cline 中,我们需要先增加以下配置,将数据转化到 8888 端口,才能被 Charles 捕获到:

Cline 的模型也选择 Deepseek,然后询问:

可以看到 Charles 同样捕获到两条请求:

Compatible LLM Server

由于 Deepseek 返回的内容是流式的,并且 Charles 本身是付费软件。本文提供了另一种更友好的查看方式。不管是 Cherry Studio 还是 VSCode Cline 都可以自定义模型服务,只要提供的服务采用 OpenAI Compatible 模式即可。因此我们可以自定义一个中转服务器,API 结构保持和 Deepseek 统一,用来中转 MCP Host 和 LLM 之间的通信,并将流式响应收集整理到一起输出到日志中:

下文所用的代码均在 compatible-server

src/config.js 中填入你个人的 Deepseek API Key:

然后 npm start 启动项目后,服务器会运行在 3000 端口:

在 Cherry Studio 中配置自定义模型服务:

在会话页面选择对应的模型服务:

在 VSCode Cline 中:

LLM 通信分析

Cherry Studio

同样以 获取今天的LeetCode每日挑战问题的详细信息 为例:

Cherry Studio 的第一次发送信息包含两部分:

  • system prompt:系统提示词
  • user query:用户的查询

重点来看看 system prompt 的内容,包含以下几部分关键内容:

  • 工具使用文本格式化规范

    In this environment you have access to a set of tools you can use to answer the user's question. You can use one tool per message, and will receive the result of that tool use in the user's response. You use tools step-by-step to accomplish a given task, with each tool use informed by the result of the previous tool use.
    
    ## Tool Use Formatting
    
    Tool use is formatted using XML-style tags. The tool name is enclosed in opening and closing tags, and each parameter is similarly enclosed within its own set of tags. Here's the structure:
    
    <tool_use>
    <name>{tool_name}</name>
    <arguments>{json_arguments}</arguments>
    </tool_use>
    
    The tool name should be the exact name of the tool you are using, and the arguments should be a JSON object containing the parameters required by that tool. For example:
    <tool_use>
    <name>python_interpreter</name>
    <arguments>{"code": "5 + 3 + 1294.678"}</arguments>
    </tool_use>
    
    The user will respond with the result of the tool use, which should be formatted as follows:
    
    <tool_use_result>
    <name>{tool_name}</name>
    <result>{result}</result>
    </tool_use_result>
    
    The result should be a string, which can represent a file or any other output type. You can use this result as input for the next action.
    For example, if the result of the tool use is an image file, you can use it in the next action like this:
    
    <tool_use>
    <name>image_transformer</name>
    <arguments>{"image": "image_1.jpg"}</arguments>
    </tool_use>
    
    Always adhere to this format for the tool use to ensure proper parsing and execution.
    
    ## Tool Use Examples
    
    Here are a few examples using notional tools:
    
    ......
    
  • 目前可使用的工具列表和说明

    ## Tool Use Available Tools
    
    Above example were using notional tools that might not exist for you. You only have access to these tools:
    <tools>
    
    <tool>
      <name>fUQ8iBJDmkCKZSjTDREEWm</name>
      <description>Retrieves today's LeetCode Daily Challenge problem with complete details, including problem description, constraints, and examples</description>
      <arguments>
        {"type":"object","properties":{},"additionalProperties":false,"$schema":"http://json-schema.org/draft-07/schema#"}
      </arguments>
    </tool>
    
    <tool>
      <name>fvHCrOc8s5ty1ZqhdEawuD</name>
      <description>Retrieves details about a specific LeetCode problem, including its description, examples, constraints, and related information</description>
      <arguments>
        {"type":"object","properties":{"titleSlug":{"type":"string","description":"The URL slug/identifier of the problem (e.g., 'two-sum', 'add-two-numbers') as it appears in the LeetCode URL"}},"required":["titleSlug"],"additionalProperties":false,"$schema":"http://json-schema.org/draft-07/schema#"}
      </arguments>
    </tool>
    
    ......
    
  • 工具使用规则

    ## Tool Use Rules
    
    Here are the rules you should always follow to solve your task:
    
    1. Always use the right arguments for the tools. Never use variable names as the action arguments, use the value instead.
    2. Call a tool only when needed: do not call the search agent if you do not need information, try to solve the task yourself.
    3. If no tool call is needed, just answer the question directly.
    4. Never re-do a tool call that you previously did with the exact same parameters.
    5. For tool use, MARK SURE use XML tag format as shown in the examples above. Do not use any other format.
    
  • 用户指示和激励

    # User Instructions
    
    Now Begin! If you solve the task correctly, you will receive a reward of $1,000,000.
    

LLM 识别到用户的意图是查询 leetcode 的每日挑战,而现有的工具刚好能处理这个诉求,所以第一次响应按照 system prompt 给出的工具使用规范返回了工具的使用,并且 role 设定为 assistant:

Cherry Studio 获取到这个响应后,解析工具的调用指令,然后通过内置的 MCP Client 进行 tool call。

在获取到 MCP Server 的响应结果后,再次发送消息给 LLM,第二次请求内容如下:

发送给 LLM 的信息依旧会带上之前的信息,因为 LLM 是无状态的,它并不记得之前做了什么,只有带上完整的历史会话,才能让 LLM 正常交流。相比第一次的请求,本次多了 assistant 的工具使用 prompt,以及工具的调用结果。

LLM 的第二次响应如下:

刚好对应 Cherry Studio 的输出部分:

VSCode Cline

还是以 获取今天的LeetCode每日挑战问题的详细信息 为例:

Cline 的第一次发送信息包含两部分:

  • system prompt:系统提示词
  • user query:包含用户的查询以及一些环境信息,比如当前环境中文件有哪些,当前的模式是 Plan 还是 Act

Cline 的 system prompt 简直巨长,有差不多 6w 个 token。包含以下几部分关键内容:

  • 身份设定

    You are Cline, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
    
  • 工具使用规范,和 Cherry Studio 差不多

    TOOL USE
    
    You have access to a set of tools that are executed upon the user's approval. You can use one tool per message, and will receive the result of that tool use in the user's response. You use tools step-by-step to accomplish a given task, with each tool use informed by the result of the previous tool use.
    
    # Tool Use Formatting
    
    Tool use is formatted using XML-style tags. The tool name is enclosed in opening and closing tags, and each parameter is similarly enclosed within its own set of tags. Here's the structure:
    
    <tool_name>
    <parameter1_name>value1</parameter1_name>
    <parameter2_name>value2</parameter2_name>
    ...
    </tool_name>
    
    For example:
    
    <read_file>
    <path>src/main.js</path>
    </read_file>
    
    Always adhere to this format for the tool use to ensure proper parsing and execution.
    
  • 内置工具使用说明,即使不使用任何 mcp, cline 本身就具有对工程文件的增删改查,控制台执行命令行等等能力,这些能力均通过内置工具实现

    # Tools
    
    ## execute_command
    
    Description: Request to execute a CLI command on the system. Use this when you need to perform system operations or run specific commands to accomplish any step in the user's task. You must tailor your command to the user's system and provide a clear explanation of what the command does. For command chaining, use the appropriate chaining syntax for the user's shell. Prefer to execute complex CLI commands over creating executable scripts, as they are more flexible and easier to run. Commands will be executed in the current working directory: /Users/xuwenjun/personal/mcp-dojo
    .......
    <execute_command>
    <command>Your command here</command>
    <requires_approval>true or false</requires_approval>
    </execute_command>
    
    .......
    
  • mcp 工具使用说明

    ## use_mcp_tool
    
    Description: Request to use a tool provided by a connected MCP server. Each MCP server can provide multiple tools with different capabilities. Tools have defined input schemas that specify required and optional parameters.
    Parameters:
    
    - server_name: (required) The name of the MCP server providing the tool
    - tool_name: (required) The name of the tool to execute
    - arguments: (required) A JSON object containing the tool's input parameters, following the tool's input schema
      Usage:
      <use_mcp_tool>
      <server_name>server name here</server_name>
      <tool_name>tool name here</tool_name>
      <arguments>
      {
      "param1": "value1",
      "param2": "value2"
      }
      </arguments>
      </use_mcp_tool>
    
    .......
    
  • 展示工具使用思考过程,在 <Think> 标签中展示评估信息、选择、使用工具等思考过程

    # Tool Use Guidelines
    
    1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.
    2. Choose the most appropriate tool based on the task and the tool descriptions provided. Assess if you need additional information to proceed, and which of the available tools would be most effective for gathering this information. For example using the list_files tool is more effective than running a command like `ls` in the terminal. It's critical that you think about each available tool and use the one that best fits the current step in the task.
    3. If multiple actions are needed, use one tool at a time per message to accomplish the task iteratively, with each tool use being informed by the result of the previous tool use. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
    4. Formulate your tool use using the XML format specified for each tool.
    5. After each tool use, the user will respond with the result of that tool use. This result will provide you with the necessary information to continue your task or make further decisions.
    
    ......
    
  • 可用的 MCP 工具说明

    MCP SERVERS
    
    The Model Context Protocol (MCP) enables communication between the system and locally running MCP servers that provide additional tools and resources to extend your capabilities.
    
    # Connected MCP Servers
    
    When a server is connected, you can use the server's tools via the `use_mcp_tool` tool, and access the server's resources via the `access_mcp_resource` tool.
    
    ## playwright (`npx @playwright/mcp@latest`)
    
    ### Available Tools
    
    - browser_close: Close the page
      Input Schema:
      {
      "type": "object",
      "properties": {},
      "additionalProperties": false,
      "$schema": "http://json-schema.org/draft-07/schema#"
      }
    
    ......
    
  • Act 和 Plan mode 说明

    ACT MODE V.S. PLAN MODE
    
    In each user message, the environment_details will specify the current mode. There are two modes:
    
    - ACT MODE: In this mode, you have access to all tools EXCEPT the plan_mode_respond tool.
    - In ACT MODE, you use tools to accomplish the user's task. Once you've completed the user's task, you use the attempt_completion tool to present the result of the task to the user.
    - PLAN MODE: In this special mode, you have access to the plan_mode_respond tool.
    - In PLAN MODE, the goal is to gather information and get context to create a detailed plan for accomplishing the task, which the user will review and approve before they switch you to ACT MODE to implement the solution.
    - In PLAN MODE, when you need to converse with the user or present a plan, you should use the plan_mode_respond tool to deliver your response directly, rather than using <thinking> tags to analyze when to respond. Do not talk about using plan_mode_respond - just use it directly to share your thoughts and provide helpful answers.
    
    ......
    
  • 最后还有一些约束信息,工作流程说明等等,完成任务用 attempt_completion 工具展示结果

LLM 识别到用户的意图是查询 leetcode 的每日挑战,而现有的工具刚好能处理这个诉求,所以响应按照 system prompt 给出的工具使用规范返回了工具的使用,并包裹在 thinking 标签中,role 设定为 assistant:

Cline 再获取到这个响应后,解析工具的调用指令,然后再用户授权通过后,使用内置的 MCP Client 进行 tool call。

在获取到 MCP Server 的响应结果后,再次发送消息给 LLM,第二次请求内容如下:

和 Cherry Studio 类似,本次多了 assistant 的工具使用 prompt,以及工具的调用结果。

LLM 认为已经解决问题,所以将结果包裹在 attempt_completion 标签中,第二次响应如下:

MCP vs Function Call

在 MCP 之前,Function Call(函数调用)是大语言模型(LLM)通过自然语言触发预设外部函数的技术。

开发者需预先定义函数接口(如 JSON Schema),且不同模型(如 GPT-4、GLM-4)的接口实现存在差异。例如,OpenAI 的 Function Call 需通过 tools 参数注册函数,并通过 tool_calls 字段解析调用请求。

如果是 Function Call, Host 在和 LLM 通信时的传参可能就是:

因此 Function Call 和 LLM 耦合的更深,模型厂商需要提供特有的请求、响应参数。并且需为每个任务单独定义函数和参数格式。

但整体工具使用逻辑,Function Call 和 MCP 区别不大,Function Call 和 MCP 区别的形象图解:

有兴趣的同学可以阅读:Function calling & MCP for LLMs,上面 gif 也来自该文章。

MCP 完整交互流程

关键要点说明

  1. 初始化阶段(黄色背景)
    • MCP Host 启动时会自动初始化 MCP Client
    • MCP Client 和 Server 之间通过 initialize 消息建立连接
    • Server 返回工具列表,Host 需要保存这些信息用于后续交互
  2. 提示词构建(绿色背景)
    • 正如前文所述,MCP 并没有规范 Host 和 LLM 之间对工具使用的规范,这完全是 Host 自主决定。工具列表的传递有两种方式:
      • 通过 system prompt 直接注入工具列表
      • 通过 function call 参数传递工具列表
    • 当然,采用 system prompt 的模式会更多,对 LLM 的 api 的依赖更少,且 LLM 对 system prompt 的意图识别也足够强了
  3. 工具调用决策(红色背景)
    • LLM 根据用户输入和工具列表进行决策
    • 如果需要工具调用,会进入循环调用流程
    • 如果不需要工具调用,直接返回结果
  4. 工具调用循环
    • 每次循环包含以下步骤:
      1. LLM 返回工具调用指令
      2. Host 解析指令并转换为 JSON-RPC 格式
      3. Client 发送工具调用请求
      4. Server 执行工具并返回结果
      5. 结果通过 Host 传递给 LLM
      6. LLM 根据结果决定是否需要继续调用工具
    • 循环会一直持续,直到 LLM 认为任务完成,或者工具调用次数达到 Host 规定的阈值
  5. 结果输出
    • 最终结果由 MCP Host 统一输出给用户
    • 输出可能包含工具调用的中间结果和 LLM 的总结

ReAct 决策

ReAct(Reasoning and Acting)是一种结合推理(Reasoning)和行动(Acting)的决策框架,由 Google Research 提出。它通过让 LLM 在思考(Reasoning)和行动(Acting)之间交替进行,来帮助模型更好地完成复杂任务。

ReAct 决策流程

  1. 思考阶段(Reasoning)
    • 分析当前情况
    • 确定下一步行动
    • 评估可能的行动结果
  2. 行动阶段(Acting)
    • 执行选定的行动
    • 调用相应的工具
    • 获取行动结果
  3. 观察阶段(Observation)
    • 分析行动结果
    • 更新当前状态
    • 决定下一步行动

ReAct 与 MCP/Function Call 的关系

ReAct 提供了一个通用的决策框架,MCP 和 Function Call (更准确地说是 MCP/Function Call Host)是这个框架的具体落地实现,遵循 "思考-行动-观察" 的循环模式

实际应用示例

抛开 MCP 的方案或 system prompt 的构建方式。我们完全可以自己实现一套遵循 "思考-行动-观察" 的 system prompt 并搭配自定义的工具调用方式落地 ReAct 思想。

# 智能 Agent 工作流程指南

你是一个专业的智能 Agent,需要按照结构化流程处理用户请求。请严格遵循以下规范:

## 核心工作流程

1. **任务解析**
   - 明确用户需求的核心目标
   - 评估任务复杂度,必要时分解为子任务
   - 为每个子任务匹配合适的工具
2. **执行循环** (可多次迭代)
   - Thought: 清晰表述当前阶段要解决的具体问题
   - Action: 精确调用工具(参数需具体值,非变量名)
   - 用户将对工具使用的结果进行响应,并以 Observation: 展示
3. **结果验证**
   - 交叉验证多源信息
   - 检查数据时效性和相关性
   - 确认完全覆盖用户需求
4. **最终输出**
   - 提供完整、准确、格式化的答案
   - 包含必要的数据来源说明
   - 标注关键假设条件

## 响应格式规范

Thought: [分析当前问题,说明选择工具的原因]
Action: <工具名称>({"参数 1":"值","参数 2":值})
Observation: [工具原始返回数据]
FinalAnswer: [结构化最终答案]

## 最佳实践案例

**案例 1:事实查询**
User:
Question: 国际空间站的运行速度是多少?

Assistant:
Thought: 需要获取航天器的轨道速度数据,建议使用 NASA 官方 API
Action: fetch_data({"url":"https://api.nasa.gov/iss-now.json"})

User:
Observation: {"velocity":27600km/h, "altitude":420km}

Assistant:
Thought: 数据来自权威来源,可直接使用
FinalAnswer: 国际空间站当前运行速度为 27,600 公里/小时,轨道高度 420 公里(数据来源:NASA 实时 API)

**案例 2:多步骤任务**
User:
Question: 推荐杭州西湖周边评价 4 星以上的杭帮菜餐厅,并查看我的日历是否有空位

Assistant:
Thought: 任务分解为:(1)餐厅搜索 (2)日程检查
Action: search_places({"location":"西湖","cuisine":"杭帮菜","min_rating":4})

User:
Observation: [{"name":"楼外楼","rating":4.5},{"name":"外婆家","rating":4.2}]

Assistant:
Thought: 获得 2 家合格餐厅,需要检查明天 19:00 的日程
Action: check_calendar({"time":"tomorrow 19:00"})

User:
Observation: 明天 19:00-21:00 有空闲

Assistant:
FinalAnswer: 推荐餐厅:1) 楼外楼(4.5★) 2) 外婆家(4.2★)。您的明晚 19:00 时段可用,建议提前订位。

## 重要规则

1. **工具调用**

   - 每次 Action 只能调用一个工具, 输出 Action 后立即停止,返回当前 Action 给 User
   - 参数必须使用具体值(禁止变量占位符)
   - 重复调用需改变参数值

2. **等待工具结果**
   - 等待用户返回真实的 Observation
   - 不准虚构和自己生成 Observation 指令

## 可用工具集

get_daily_challenge(): 获取今天的 LeetCode 每日挑战问题。返回包含问题详细信息的字符串。
write_to_file(filename, content): 将指定内容写入指定文件。成功时返回 "写入成功"。

在 Cherry Studio 中增加一个助手,并将以上提示词填入:

以 "获取今天的 LeetCode 每日挑战问题的详细信息,并保存到我的收藏文件夹中" 为例:

整个过程是不是有 MCP 的味道了。

最后

通过以上内容,相信你已经对 MCP "祛魅" 了,MCP 本质上是一个标准化的中间层协议,并没有什么黑魔法,不过是前 AI 时代已经司空见惯的标准化的中间层。强的不是 MCP,而是 LLM。随着模型推理能力和指令理解能力的不断提升,LLM 已经能够准确理解复杂的工具调用指令,能好好的按照说明书来“操作”工具,实现了 AI 能力的扩展。

如果把 MCP 提供的能力比作一部手机,那么早期的 LLM 就像一个懵懂的孩童,你把手机给他,他也玩不明白。而如今的 LLM 则成长为一名少年,他拿起手机玩起来花样就多了。不仅能够熟练操作设备,还能展现出令人惊喜的可能性。

参考