MCP（Model Context Protocol）的理解和快速实践，看我这篇就够了！

开发完可以先使用 mcp 的 Inspector 工具（Inspector - Model Context Protocol [8]）对 Server 进行调试，使用 “Tools” 中的 “List Tools” 可以列出所有可用工具，有对应的 name 和 description。当然，上述有个潜在的问题，无论是否使用 tool，都需要把全量 Tools 传入 LLM，必然造成输入 Token

AI大模型系统化学习

4623人浏览 · 2025-04-25 17:20:59

AI大模型系统化学习 · 2025-04-25 17:20:59 发布

一、背景

在最初接触 MCP 时，也曾对其一些设计感到困惑。于是带着这些疑问进行了进一步的调研，逐渐对 MCP 的组成及运作方式有了初步的认识，比如：

MCP 中的 Resource、Prompt、Tool、Sampling、Root 是什么，有什么用。
谁来决定是否调用 Client。
如何判断调用哪些 Client。
Client 和 Server 之间如何传输，协议是什么。
怎么使用 Prompt。

本文将尝试基于这些问题，对 MCP 进行一番介绍和解析。

二、MCP 架构

2.1 引言

Anthropic 的 MCP 是一种开放标准协议，旨在简化 Agent/LLM 与外部数据源和工具之间的集成过程。它提供了一种统一的方式，使 AI 模型能够高效、安全地访问和利用各种资源。

学习AI大模型是一项系统工程，需要时间和持续的努力。但随着技术的发展和在线资源的丰富，零基础的小白也有很好的机会逐步学习和掌握。【点击蓝字获取】

如下图所示，可以将 MCP 理解为一个 “AI 的 USB 接口”，提供了一个连接标准，使 Agent/LLM（如 Claude、ChatGPT、Qwen）能够方便、安全的访问各种外部工具和数据（比如 Gmai、Slack、本地文件等）：

传统方式的问题：每个服务（Gmail、Slack、Calendar）都有自己独特的 API，每一个 Agent（LLM）都需要各自去适配。如果有 M 个 Agent、N 个服务，则相应的复杂度为 M x N。
MCP 的优势：MCP 对各个服务的接口进行了统一，这样 M 个 Agent 可以直接使用这 N 个服务，大幅降低重复开发和适配的成本。随着更多组织或者开发者开始采用 MCP，其有望成为 AI 应用集成的主流协议。

2.2 MCP 架构概览

如下图所示（来自：Visual Guide to Model Context Protocol (MCP) [2]）为 MCP 的关键架构，受到 Language Server Protocol（LSP）的启发，旨在标准化 AI 与外部系统的交互方式，包括 3 个关键组件：

Host：通常是 AI 应用（Agent），比如 Anthropic Claude Desktop、Cursor、Cline 等，负责选择并调用 MCP Client，以便使用各种 MCP Server 提供的能力。
Client：Host 内的连接器，负责与 Server 建立 1 对 1 的连接，以便使用 Server。
Server：提供资源、工具或 Prompts 的服务，如文件系统、数据库、API 等。

如上图所示，Client 和 Server 之间使用双向的 JSON-RPC 2.0 进行通信。当前支持 stdio 和 Streamable HTTP 两种传输机制。

stdio：Client 以子进程方式启动 MCP Server，并通过标准输入输出建立通信管道。Server 从 stdin 中读取 JSON-RPC 消息（可以是 Request、Response 或 Notification），并将消息发送到 stdout。（PS：Server 不能往 stdin 写，Client 不能往 stdout 写）
Streamable HTTP + SSE：Client 发起 HTTP GET 并在 Accept: text/event-stream 下打开 SSE 流；Server 在该流上通过 SSE 推送 JSON‑RPC Request 和 Notification，Client 监听并处理。Client 再通过 HTTP POST 将对应的 JSON‑RPC 响应提交至同一 MCP 端点，实现完整的双向交互。
WebSocket：Transport Layer 也支持自定义的传输机制，比如常见的 WebSocket。Server 和 Client 均可充当 JSON‑RPC 请求的发起者和接收者；Client 在连接时注册自己支持的 method，Server 即可通过同一通道调用这些方法。

2.3 MCP 关键概念

2.3.1 Resources

Resources 在 MCP 中指的是 AI 可以访问和读取的数据来源。这些数据包括但不限于文件内容、数据库记录、屏幕截图、图像、日志文件、API 响应等。每一个 resource 都有一个独立的 URI，包含文本或者二进制数据，其可以为 AI 提供所需的上下文信息。如下所示为使用 MCP 的 Python SDK（The official Python SDK for Model Context Protocol servers and clients [3]）在 MCP Server 中实现 Resource 的简单示例：

list_resources()：用于列出所有 resource（列表），以便后续选择、访问。resource 对应的数据类型为 types.Resource，其包含唯一的 uri，也有对应的 mimeType。
read_resource()：根据 uri 访问对应的 resource。

2.3.2 Prompts

Prompts 是预定义的模板或指令，旨在指导 AI 生成响应或执行特定任务。它们是 MCP 扩展性的一部分，允许开发者根据具体需求创建新的 Prompt 模板，以增强 AI 与数据源的交互。如下所示为使用 MCP Python SDK 在 MCP Server 中实现 Prompt 的简单示例：

list_prompts()：列出所有可用的 Prompt（列表）。prompt 对应的类型为 types.Prompt，包含唯一的 name，必要的 description 以及一个 arguments 列表。
get_prompt()：根据 name 获取对应的 Prompt，返回的是 GetPromptResult，包含 description 和 messages 属性。

Prompts 在 Anthropic 的分类中属于“用户控制”（user‑controlled）级别，意味着最终由用户在客户端界面中主动选择并执行，具有以下特性：

动态参数：支持在调用时传入变量，生成个性化提示。
资源上下文：可将文件、日志等资源内容嵌入到提示中。
流程编排：可链式组合多轮交互，实现复杂工作流。

2.3.3 Tools

Tools 是 MCP Server 提供的功能（PS：也是当前使用最多，支持最好的功能），AI 可以调用这些功能执行具体操作，如运行代码、访问外部 API 或自动化任务。这些工具需要用户批准，确保安全性和可控性。和 Resources 类似，工具也需要包含唯一的 name，并且包含相应的描述（description），以便引导更好的使用该工具。如下所示为使用 MCP 的 Python SDK 在 MCP Server 中实现 Tools 的简单示例：

list_tools()：列出所有可用 Tools（列表）。tool 对应的类型为 types.Tool，同样包含唯一的 name，必要的 description，以及相应的 inputSchema（对应 Anthropic Claude function call 中的 input_schema）。
call_tool()：根据 name 以及对应的 arguments 调用相应的 tool，比如这里是执行相应的求和计算。

2.3.4 Sampling

Sampling 允许 Server 通过 Client 请求 LLM 完成生成，支持复杂的代理行为，同时保持安全性和隐私。不过当前 Sampling 特性在 Claude Desktop client 中还未支持。Sampling 扩展了 MCP 的 Client-Server 架构，使得 Server 无需自行承载或调用远端模型，就能通过 Client 访问预制的 LLM 能力，实现更强的交互能力。典型的流程包含如下 5 个步骤：

Server 调用 sampling/createMessage 向 Client 发送请求（PS：可以双向通信）。
Client 接收后，可根据策略或人工审核，对请求进行修改或拒绝。
Client 在本地或受信任环境中调用 LLM 执行生成采样。
Client 可再次审核生成的 completion，并对结果进行过滤或调整。
Client 将最终的 completion 通过 JSON-RPC 响应返回给 Server。

2.3.5 Roots

Roots 定义了 Server 可以操作的边界。root 可以作为 URI，当 Client 连接 Server 时，声明 Server 需要关注的范围。主要是用于文件系统路径（如file:///home/user/projects/myapp）或 HTTP URL（如 https://api.example.com/v1），帮助服务器了解相关资源和位置，明确工作空间资源，并支持同时处理多个资源。如下图所示为 MCP Client 声明 roots 的典型方式，此配置表明 Server 同时聚焦于本地仓库与远程 API 端点，且在逻辑上保持二者独立。

2.4 能力协商机制

MCP 采用基于能力的协商机制，Client 和 Server 需要在初始阶段声明各自支持的“能力”特性。“能力”声明决定了会话阶段可使用的协议特征和基本操作。

初始阶段：
- Server 需要声明：可用 Resource、支持的 Tool、Prompt 模板。
- Client 需要声明：Sampling 支持，Notification 处理。
会话阶段：Client 和 Server 需要严格遵守已声明的能力范围。

如下图所示展示初始阶段和会话阶段的几个过程：

红框：初始阶段，Host 调用 Client，Client 访问 Server 获取 Server 可支持的资源和能力（list_resources()，list_tools()）。
蓝框：会话阶段（Host 发起），Host 中用户或模型发起 Action，调用 Client，Client 请求 Server 来获取资源或执行工具（read_resource()，call_tool()）。
绿框：会话阶段（Server 发起），Server 调用 Client 获得 Sampling 支持，Client 转发给 Host 并获取响应，然后返回给 Server。

三、实现细节

3.1 Tools 和 Resources 管理

在 Python SDK 中，Server 侧使用 ToolManager 管理当前 Server 的所有 Tool，并提供 list_tools() 和 call_tool() 方法：

Host 端会管理所有的 Client，通过这些 Client 可以管理所有 Server 的所有 Tools。如下图所示，OpenAI 的 Agents 库中提供了 get_all_function_tools() 来获取所有 Server 的所有 Tools（openai-agents-python/src/agents/mcp/util.py [4]），并且不允许 Tool name 有重复（即使在不同的 Server）：

PS：不同的 Host 可以实现不同的管理方式，但是最终将这些 Tools 传入 LLM 的方式都类似。此外，管理 Resources 的机制也类似。

3.2 与 LLM 的结合

3.2.1 Function Call

有了 Tools 和 Resources，Host 是怎么判断使用哪个 Server 的哪个 tool/resource 呢？其实和之前的 AI Agent 没有什么本质区别。依然是将可用的 tool 和 resource 传入 LLM，依赖 LLM 的 Function Call 能力来智能选择。

如下图所示为 OpenAI 的 Function Call（Function calling - OpenAI API [5]）调用方式及 Anthropic Claude 的 Function Call（Tool use with Claude - Anthropic [6]）调用方式，整体基本一致，只是一个是 “parameters”，一个是“input_schema”。Qwen （Function Calling - Qwen [7]）也基本类似，替换使用的 LLM 的成本也相对比较低。

3.2.2 Server & Tool 选择

当前常见的 Host 中不会特意选择 Server，而是将所有 Server 的 Tools 汇总，一起交由 LLM 来选择。而 Tools 越多，就会导致 LLM 的 Input Token 数越多，造成 LLM 调用成本的增加，也可能导致效果的降低。如下所示，OpenAI Function Call 的文档中建议 Tools 的数量不超过 20 个（Function calling - OpenAI API [5]）

除此之外，有些场景并不需要使用 Tools，为此 OpenAI 中也提供 tool_choice 选项：

Auto：表示由 LLM 判断是否使用 tool，以及使用哪些 tool。
Required：表示必须使用至少一个 tool。
Forced Function：表示强制使用某个 tool。

当然，上述有个潜在的问题，无论是否使用 tool，都需要把全量 Tools 传入 LLM，必然造成输入 Token 数的增加，也就是成本的增加（PS：也可以通过 Prefix Cache 缓解）。随着 MCP 的发展，Tools 的数量会越来越多，此时就会需要一种低成本的机制，调用 LLM 之前对 Tools 进行粗筛，然后再供 LLM 选择。

3.3 MCP Prompt 的使用

在 MCP 中，Prompts 是服务器向客户端暴露的“用户可控”模板，用于标准化和复用与大模型交互的常见流程。Client 可以通过 JSON‑RPC 调用 prompts/list 发现可用模板，再通过 prompts/get 获取具体的消息序列（messages），并可传入动态参数或嵌入资源上下文，从而自动化地生成用户与模型之间的交互内容。相应的过程如下图所示：

Discovery：调用 prompts/list 方法，获得所有可用 Prompts，对应我们前面介绍的 list_prompts()。
Usage：调用 prompts/get 方法，并传入必要的参数，以便组装 Prompt 或者嵌入资源（Resource）上下文，对应我们前面介绍的 get_prompt()。
Changes：Server 也可以更新 Prompt 并通知 Client（notifications/prompts/list_changed）相应的变更，Client 需要重新获取 Prompts。

四、示例

4.1 MCP Server 开发和验证

可以参考 The official Python SDK for Model Context Protocol servers and clients [3] 中的示例快速实现一些 Demo。如下图所示，我们在 Demo Server 中提供两个 Tool：

pack：给定两个整数，返回的是打包过程，这里我们求和并额外加了 1000000，以便区分 LLM 自己生成的结果。
get_paper_abstract：给定一个 Arxiv 论文的 ID，返回对应论文的摘要。

开发完可以先使用 mcp 的 Inspector 工具（Inspector - Model Context Protocol [8]）对 Server 进行调试，使用 “Tools” 中的 “List Tools” 可以列出所有可用工具，有对应的 name 和 description。选中对应工具并输入相关参数即可以 “Run Tool” 并获得结果：

4.2 Claude Desktop 集成 MCP Server

验证完 Server 的正确性即可以将其集成到 Claude Desktop 中使用。首次使用可以创建一个空的 “~/Library/Application\ Support/Claude/claude_desktop_config.json” 文件并编辑，即可激活 Claude Desktop 的 MCP 支持。如下所示，可以在 claude_desktop_config.json 中配置相应的 McpServers，这里是一个 Dict，可以配置多个 Server。这里用 uv 管理 Python 环境，command 中最好写上绝对路径，不然在 Mac 中可能异常：