Lazy loaded image
一文读懂 MCP 原理
字数 2407阅读时长 7 分钟
2025-5-14
2025-5-14
type
status
date
slug
summary
tags
category
icon
password

一、什么是 MCP

MCP (Model Context Protocol)是一种开放标准协议,旨在简化 Agent/LLM 与外部数据源和工具之间的集成过程。可以把 MCP 想象成人工智能应用程序的 USB-C 接口。就如同 USB-C 接口为将设备连接到各种外围设备和配件提供了一种标准化的方式一样,MCP 为将人工智能模型连接到不同的数据源和工具提供了一种标准化的方式。
  • 传统方式的问题:每个服务(Gmail、Slack、Calendar)都有自己独特的 API,每一个 Agent(LLM)都需要各自去适配。如果有 M 个 Agent、N 个服务,则相应的复杂度为 M x N。
  • MCP 的优势:MCP 对各个服务的接口进行了统一,这样 M 个 Agent 可以直接使用这 N 个服务,大幅降低重复开发和适配的成本。
 
notion image

二、MCP 通用架构

MCP 遵循 CS 架构(client-server),具体包含的组件如下:
  • Host:发起连接 LLM 的应用程序,例如 Claude for Desktop 或其他的 AI 应用。
  • MCP Client:运行在 Host 里的客户端,与 MCP Server 服务器保持 1:1 连接,负责协议通信。
  • MCP Server:负责向客户端提供工具(Tools)、资源(Resources)、 Prompts (Prompts)的服务器。
 
notion image
MCP使用JSON-RPC对消息进行编码。JSON-RPC消息必须采用UTF-8编码。MCP提供两种标准传输实现:
  • Standard Input/Output (stdio) 标准输入/输出
    • stdio传输支持通过标准输入和输出流进行通信。
    • 适用于本地集成和命令行工具。
    •  
  • Streamable HTTP
    • Client 以普通 HTTP 请求为基础,使用 POST/GET 发请求。
    • Server 可选地将响应升级为 SSE 流,实现流式传输的能力。
    • 在Streamable HTTP传输中,服务器作为一个独立的进程运行,可以处理多个客户端连接。
    • 适用于使用远程服务。
    •  
具体细节:MCP-Transports
 

三、MCP Server

在 MCP 协议中,Server 提供了为 LLM 大模型添加上下文的基础构件。通过 Propmts(提示词)、Resources(资源)和 Tools(工具) 实现 客户端、服务器与 LLM 之间实现高效且灵活的交互。
 
notion image

1.Tools(工具)

Tools 是 MCP Server 使用最多,支持最好的功能,Agent/LLM 可以调用这些功能执行具体操作,如运行代码、访问外部 API 或自动化任务。使用时需要包含唯一的 name,并且包含相应的描述(description),以便引导更好的使用该工具。
 

2.Resources(资源)

Resources 在 MCP 中指的是 AI 可以访问和读取的数据来源。这些数据包括但不限于文件内容、数据库记录、屏幕截图、图像、日志文件、API 响应等。每一个 resource 都有一个独立的 URI,包含文本或者二进制数据,其可以为 AI 提供所需的上下文信息。
 
 

3.Prompts(提示词)

 
Prompts 是预定义的模板或指令,旨在指导 AI 生成响应或执行特定任务。它们是 MCP 扩展性的一部分,允许开发者根据具体需求创建新的 Prompt 模板,以增强 AI 与数据源的交互。
 
 

四、MCP 原理

MCP 的核心功能是便于调用多个工具,由此引发一个问题:LLM 何时确定使用哪些工具?即模型如何智能选择 Agent 或工具?用户提问后,具体流程如下:
  1. 客户端(Claude Desktop / Cursor)将 Prompt 和 MCP Server 中的工具描述 发送给 LLM
  1. LLM 分析可用工具,选择使用一个或多个
  1. 客户端通过 MCP Server 执行所选工具并将执行结果被送回给 LLM
  1. LLM 结合结果归纳总结,以自然语言呈现给用户。
 
notion image
首先我们要理解模型是如何确定该使用哪些工具?参考 MCP 官方提供的 Client example 为讲解示例。
 
 
上述 tool 的名字、描述、参数 又是从哪里获取的呢?通过分析 MCP Server 的 Python SDK 源代码可以发现:大部分情况下,当使用装饰器 @mcp.tool() 来装饰函数时,对应的 name 和 description 等其实直接源自用户定义函数的函数名以及函数的 docstring 等。这里仅截取一小部分片段,想了解更多请参考原始代码。
 
 
工具的执行就比较简单和直接了。承接上一步,我们把 system prompt(指令与工具调用描述)和用户消息一起发送给模型,然后接收模型的回复。LLM 分析用户请求后,它会决定是否需要调用工具:
  • 无需工具时:模型直接生成自然语言回复。
  • 需要工具时:模型输出结构化 JSON 格式的工具调用请求。
 
如果回复中包含结构化 JSON 格式的工具调用请求,则客户端会根据这个 JSON 代码执行对应的工具。具体的实现逻辑都在 process_llm_response 中,代码、逻辑非常简单。
 
如果模型执行了 tool call,则工具执行的结果 result 会和 system prompt 和用户消息一起重新发送给模型,请求模型生成最终回复。
 
 
根据上述原理分析,可以看出工具文档至关重要。模型依赖于工具描述文本来理解和选择适用的工具,这意味着精心编写的工具名称、文档字符串(docstring)以及参数说明显得尤为重要。
 
鉴于MCP的选择机制基于prompt实现,理论上任何模型只要能够提供相应的工具描述就能与MCP兼容使用。
 

参考资料

上一篇
38G国内教材开源数据(转)
下一篇
tb直播抓取

评论
Loading...