模型上下文协议（MCP）完全指南

📢 转载信息

原文链接：https://machinelearningmastery.com/the-complete-guide-to-model-context-protocol/

原文作者：Bala Priya C

---

在本文中，您将了解到模型上下文协议（Model Context Protocol，MCP）是什么、它为何存在，以及它如何标准化语言模型与外部数据和工具的连接方式。

我们将涵盖的主题包括：

• MCP旨在解决的集成问题。
• MCP的客户端-服务器架构和通信模型。
• 核心原语（资源、提示和工具）及其协同工作方式。

我们不要再浪费时间了。

介绍模型上下文协议

语言模型可以令人印象深刻地生成文本和进行推理，但默认情况下它们仍然是孤立的。开箱即用时，如果没有额外的集成工作，它们无法访问您的文件、查询数据库或调用API。每当有新的数据源时，都需要更多的定制代码、更多的维护负担和更多的碎片化。

模型上下文协议（MCP) 通过提供一个开源标准，用于将语言模型连接到外部系统来解决这个问题。MCP提供了一个共享协议，而不是为每个数据源构建一次性集成，该协议允许模型与工具、API和数据进行通信。

本文将深入探讨MCP是什么、它为何重要，以及它如何改变我们连接语言模型与现实世界系统的方式。以下是我们将要涵盖的内容：

• MCP旨在解决的核心问题
• MCP架构概述
• 三大核心原语：工具、提示和资源
• 协议流程在实践中如何运作
• 何时使用MCP（以及何时不使用）

到最后，您将对MCP如何在现代AI堆栈中发挥作用以及如何决定它是否适合您的项目有一个扎实的理解。

模型上下文协议解决的问题

在MCP出现之前，将AI集成到企业系统中既混乱又效率低下，因为将语言模型与实际系统绑定很快就会遇到可扩展性问题。每个新的模型和每个新的数据源都需要定制的集成代码——连接器、适配器和API桥梁——这些代码是无法泛化的。

如果您有 M 个模型和 N 个数据源，您最终需要维护 M × N 个唯一的集成。每增加一个新模型或数据源，复杂性就会成倍增加，从而增加维护开销。

MCP通过引入模型与外部资源之间通信的共享标准来解决这个问题。不再是每个模型都直接与每个数据源集成，而是模型和资源都使用一种通用协议进行通信。这会将 M × N 的问题转化为 M + N 的问题。每个模型实现一次MCP，每个资源实现一次MCP，然后所有内容都可以顺利地互操作。

简而言之，MCP将语言模型与外部集成的特定细节解耦。通过这样做，它能够实现可扩展、可维护且可重用的连接，将AI系统链接到真实世界的数据和功能。

理解MCP的架构

MCP实现了一种具有特定术语的客户端-服务器架构，理解这些术语很重要。

三大关键组件

MCP 宿主（Hosts） 是想要使用MCP功能的应用程序。这些通常是LLM应用，如Claude桌面版、具有AI功能的IDE，或您自己构建的定制应用。宿主包含或接口语言模型，并启动与MCP服务器的连接。

MCP 客户端（Clients） 是由宿主应用程序创建和管理的协议客户端。当宿主想要连接到MCP服务器时，它会创建一个客户端实例来处理该特定连接。单个宿主应用程序可以维护多个客户端，每个客户端连接到不同的服务器。客户端处理协议级别的通信，根据MCP规范管理请求和响应。

MCP 服务器（Servers） 向客户端暴露特定功能：数据库访问、文件系统操作、API集成或计算工具。服务器实现协议的服务器端，响应客户端请求并提供资源、工具和提示。

这种架构提供了清晰的关注点分离：

• 宿主专注于编排AI工作流程，而无需关心数据源的具体细节。
• 服务器暴露功能，而无需知道模型将如何使用它们。
• 协议透明地处理通信细节。

单个宿主可以通过单独的客户端同时连接到多个服务器。例如，一个AI助手可能同时维护到文件系统、数据库、GitHub和Slack服务器的连接。宿主向模型呈现一个统一的功能集，抽象了数据是来自本地文件还是远程API。

通信协议

MCP使用JSON-RPC 2.0进行消息交换。这种轻量级的远程过程调用协议提供了一种结构化的请求/响应格式，易于检查和调试。

MCP支持两种传输机制：

• stdio（标准输入/输出）：用于在同一台机器上运行的本地服务器进程。宿主生成服务器进程并通过其标准流进行通信。
• HTTP：用于网络通信。使用HTTP POST进行请求，并可选地使用Server-Sent Events进行流式传输。

这种灵活性使得MCP服务器可以在本地或远程运行，同时保持通信的一致性。

三大核心原语

MCP依赖于服务器暴露的三大核心原语。它们提供了足够的结构来实现复杂的交互，而不会限制灵活性。

资源（Resources）

资源代表模型可以读取的任何数据。这包括文件内容、数据库记录、API响应、实时传感器数据或缓存的计算结果。每种资源都使用URI方案，便于识别和访问不同类型的数据。

以下是一些示例：

• 文件系统：file:///home/user/projects/api/README.md
• 数据库：postgres://localhost/customers/table/users
• 天气API：weather://current/san-francisco

URI方案标识资源类型。路径的其余部分指向特定的数据。资源可以是静态的，例如具有固定URI的文件；也可以是动态的，例如持续更新日志中的最新条目。服务器通过resources/list端点列出可用资源，宿主通过resources/read检索它们。

每种资源都包含元数据，例如MIME类型（这有助于宿主正确处理内容——text/markdown的处理方式与application/json不同）以及描述性信息，为用户和模型提供上下文理解资源。

提示（Prompts）

提示为常见任务提供可重用的模板。它们编码了专业知识并简化了复杂的指令。

例如，数据库MCP服务器可以提供analyze-schema（分析模式）、debug-slow-query（调试慢查询）或generate-migration（生成迁移）等提示。每个提示都包含任务所需的上下文。

提示接受参数。一个analyze-table（分析表）提示可以接受表名，并包含模式详细信息、索引、外键关系和最近的查询模式。特定领域系统从专业提示中受益最多。Kubernetes MCP服务器可以提供用于集群问题故障排除的提示。代码审查服务器可以提供与团队风格指南保持一致的提示。提示使MCP服务器携带专业知识，而不仅仅是数据。

工具（Tools）

工具是模型可以调用以执行操作或计算的函数。与资源（通常是只读的）或提示（提供指导）不同，工具会修改状态。工具允许模型采取行动，而不仅仅是观察。

每个工具都使用JSON Schema定义参数、类型和约束。模型发送一个与该Schema匹配的JSON对象。服务器对其进行验证、执行操作并返回结果。

GitHub MCP服务器可能包含create_issue（创建问题）、merge_pull_request（合并拉取请求）、add_comment（添加评论）和search_code（搜索代码）。每种工具都有一个清晰的契约。它指定了它期望的参数、它返回的内容以及它产生的副作用。

工具执行需要仔细控制，因为工具可能会修改数据或触发外部操作。宿主会协调所有调用。它可以强制执行确认、日志记录和访问控制。MCP提供了这些保障措施的框架，同时保持实现灵活性。

协议通信流程

了解MCP宿主和服务器如何通信，可以说明为什么该协议既实用又有效。所有交互都遵循基于JSON-RPC基础构建的可预测模式。

初始化握手

宿主和MCP服务器之间的通信始于一个建立连接并协商支持的功能的握手过程。宿主上的MCP客户端首先发送一个初始化请求。该请求包括其协议版本以及它能处理的功能声明。

服务器以其自身的能力以及名称、版本和支持的MCP原语（工具、资源、提示）等标识信息作为回应。这种交换允许双方发现对方能做什么，并确保跨协议版本的兼容性。如果客户端和服务器没有共享兼容的版本，应终止连接以防止错误。

初始化完成后，服务器可以开始通告资源、提示和工具。这种两步握手确保双方在任何实质性通信开始之前都已准备就绪。

发现能力

初始化完成后，宿主可以查询服务器以了解可用的功能。

• 对于资源，它调用resources/list以获取可访问的URI目录。
• 对于提示，prompts/list返回可用的模板和参数。
• 对于工具，tools/list提供所有带有其JSON Schema的函数。

这些发现机制使MCP服务器具有自我文档性。宿主可以连接到不熟悉的服务器并自动学习它们可以访问的内容。无需手动设置或配置文件。

发现也可以是动态的。随着目录内容的变化，文件系统服务器可能会列出不同的文件。数据库服务器可能会根据用户权限暴露不同的表。这确保了协议适应现实状态。

执行操作

使用MCP，访问资源变得很直接。客户端发送一个带有资源URI的resources/read请求。服务器返回内容、MIME类型和相关元数据。

工具调用遵循类似的模式。模型构建一个带有工具名称和参数的JSON对象。客户端发送一个tools/call请求。服务器验证、执行并返回结果。如果执行失败，它会返回一个结构化的错误来解释问题。

提示的工作方式略有不同。要检索提示，客户端调用prompts/get并提供提示名称和任何参数。服务器返回扩展后的提示文本，该文本整合了参数和动态上下文。然后，宿主可以将此作为输入发送给模型。

错误处理和边缘情况

MCP定义了基于JSON-RPC约定的一套标准错误代码。解析错误、无效请求、方法未找到和无效参数都有一个特定的代码。服务器一致地返回这些代码，使错误处理对宿主来说是可预测的。

该协议还处理超时和取消。长时间运行的操作如果条件发生变化或用户失去兴趣，可以被取消。服务器应在取消发生时执行清理工作，以防止资源泄漏并保持一致状态。

何时（不）使用MCP

MCP为AI应用程序连接外部数据和工具提供了一种标准方式，但它并非总是正确的选择。

用例

当AI应用需要结构化地访问外部功能时，MCP效果最佳。那些需要读取数据、调用工具或与多个系统交互的应用可以从其清晰的抽象中受益。

拥有大量集成的系统能获得最大的优势。不再需要为每项服务编写定制代码，您只需实现一次MCP并连接到标准服务器。这会将复杂性从单个应用程序转移到可重用的基础设施。

需要审计跟踪的应用也受益于MCP。每项操作都通过定义的报文流动，使日志记录、分析和合规性工作变得更简单。

MCP不太适用的场景

对于简单的提示和响应应用，MCP会带来不必要的开销。如果系统只向模型发送文本并显示回复，直接交互会更简单。

具有单一集成的单用途工具可能不值得使用MCP。一个仅访问GitHub的项目可以直接调用其API。当需要对多个集成进行标准化时，MCP最有用。

需要超低延迟的应用可能会发现MCP的JSON-RPC层比直接API稍重。对于毫秒级的关键工作流程，直接连接可以更快。

总结：当结构化访问、多重集成和清晰的通信流程的重要性超过其开销时，请使用MCP。对于简单或高度受限的应用，请避免使用它。

结论

MCP促进了AI功能与使其真正有用的信息和工具之间的连接。MCP帮助我们从孤立的应用程序发展到集成化的、有能力的系统。模型不再局限于其训练数据；它们通过连接获得新能力。同一个基础模型可以根据它可以访问的MCP服务器，充当编码助手、数据分析师或客户服务代理。

对于开发人员而言，MCP为构建更强大的AI应用提供了清晰的路径。对于组织而言，它在不产生供应商锁定的情况下实现了AI集成的标准化。对于更广泛的AI社区而言，它为可互操作的系统建立了共同基础。

请参阅“参考与深入阅读”部分，获取详细指南、示例和参考资料，以帮助您有效地理解和实施MCP。

参考与深入阅读

• MCP 规范
• 模型上下文协议概述
• MCP SDKs
• 什么是模型上下文协议（MCP）？Google Cloud 指南
• 模型上下文协议（MCP）——LangChain 文档
• 快速入门指南——FastMCP

---

🚀 想要体验更好更全面的AI调用？

欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。