模型上下文协议(MCP,Model Context Protocol的缩写) 是一个开放标准,旨在将AI助手与实际存储数据的系统连接起来——从内容库和业务工具到开发环境。本质上,MCP在大型语言模型(LLM)应用程序与外部数据或功能之间建立了一个通用接口。Anthropic(Claude AI助手背后的团队)在2024年底引入了MCP,以解决AI中日益增长的集成挑战。开发人员不再需要为每个数据库、API或知识库单独构建插件或自定义连接器,而是可以使用MCP作为通用协议,任何AI应用程序(客户端)和任何数据源(服务器)都能识别。这极大地简化了AI系统如何获取上下文(相关信息)并代表用户执行任务。
将MCP想象成AI应用的“USB-C端口”——一个标准化的即插即用接口,用于连接各种工具和数据。就像USB-C使得许多设备可以无视制造商互相兼容一样,MCP制定了通用规则,使得任何使用大语言模型的客户端都能与任何符合MCP规范的服务器通信。这种标准化类似于编程环境中语言服务器协议(LSP)所做的工作:LSP使得任何代码编辑器都能通过一个通用协议支持任何编程语言,从而将M×N的集成问题转化为M+N。
关键是减少你需要管理的直接交互操作数量。在一个 M×N 集成设置中,来自第一个组的每个组件都需要与第二个组中的每个组件进行连接,导致 M×N 个配对。相反,当你将其转换为基于 M+N 的 LSP 方法时,让每个 M 组件和每个 N 组件与中心协议(在这里是语言服务器协议)进行通信。这意味着你只需要管理 M+N 个连接,而不是每一对连接。
同样,MCP简化了复杂的自定义AI集成,形成了一个更易管理的生态系统——AI助手和数据/服务只需实现一次MCP,就能相互协作。目标是实现一个更贴近实际、更新的AI(访问实时的数据)以及一个更可持续的集成生态系统,在这个生态系统中,对一个MCP服务器的改进将使所有兼容的客户端受益。
MCP架构示意图 — MCP利用MCP客户端连接AI应用,例如Claude或IDE等。每个服务器就像是一个“外设”——无论是远程服务(比如Slack、Gmail、日历API等)还是本地数据(比如文件、数据库),所有这些都通过统一的MCP接口进行连接。这让AI助手能够通过一个标准化中心无缝接入多种数据源和工具。
MCP的关键组件MCP的设计采用了客户端-服务器架构(客户端-服务器体系结构),清晰地划分了人工智能应用和数据连接器的角色。此架构的关键组件有:
- MCP 主机(AI 应用) — 需要外部信息或功能支持的 AI 或 LLM 应用程序。主机可以是聊天机器人、IDE 或任何嵌入了 LLM 的工具。例如,Claude 桌面应用、代码编辑器(如 Cursor)、聊天机器人界面都可以充当 MCP 主机。主机负责协调 LLM 的操作,管理多个连接,并将 AI 输出与检索到的上下文合并。它通常集成一个或多个 MCP 客户端。
- MCP 客户端 — 客户端是主机应用程序中的一个组件(通常是库或进程),负责与 MCP 服务器建立 一对一的连接。每个数据源或工具都会有自己的客户端实例。客户端处理与服务器的所有信息交换,路由请求/响应,并记录服务器可以做什么。它们还处理会话细节,比如初始化连接和与服务器协商功能等。它们还处理会话细节,比如初始化连接和与服务器协商功能等。
- MCP 服务器 — 服务器是轻量级的程序或服务,通过 MCP 接口暴露特定的数据或功能。服务器可以封装本地资源(如文件系统或数据库)或远程服务(如 Slack、Gmail、GitHub 等)。每个服务器都以标准化的方式提供一个或多个 功能,因此,任何 MCP 客户端都可以查询或调用这些功能。主机不需要为 Google Drive、Slack 或 SQL 数据库等编写自定义代码,每个都可以有自己的 MCP 服务器,主机只需通过 MCP 与它们通信即可。早期的一些服务器示例包括 Google Drive、Slack、Git 存储库、Postgres 数据库等的连接器。
- MCP 协议(基础协议) — 这是客户端和服务器用来通信的语言和规则。MCP 使用 JSON-RPC 2.0 作为消息格式,并定义了一套用于常见任务(初始化、列出功能、调用工具等)的方法和消息类型。通信可以通过不同的传输方式实现 — 通常是 标准输入/输出流(stdio)(对于本地服务器,由主机启动)或 HTTP 服务器发送事件(SSE)(对于远程服务器)。协议层负责消息的编码、交换和会话管理(例如,保持连接以处理多个请求)。
MCP服务器到底能提供什么?协议定义了服务器可以提供给AI模型的三大主要功能类别。
- 资源 — 只读的数据,模型可以作为上下文检索的数据。资源类似于文件或文档:它们有模型可以读取的内容,但获取这些数据不应触发繁重的计算或产生副作用。示例包括文档的文本、数据库记录的内容、维基页面或任何由URI(统一资源标识符)标识的静态内容。在MCP系统中,资源通常由URI样式的标识符引用(例如,服务器可能会定义一个资源
users://{id}/profile
,以通过ID获取用户概况)。客户端可以请求资源,服务器返回要插入到LLM上下文(提示)中的内容。资源为AI提供了实时数据基础——而不是完全依赖于模型的训练,模型可以按需提供最新信息。 - 工具 — 可执行函数或操作,模型可以调用(通常需要用户许可)。工具让AI能够做比单纯读取数据更多的事情:它们可以执行计算、查询API、发送消息、更新记录等。每个工具都定义了名称、描述和输入模式,指定它期望的参数。例如,服务器可能有一个工具
get_weather(latitude, longitude)
,返回给定坐标处的当前天气。AI模型可以根据需要调用此工具——类似LLM使用计算器或调用API的功能。工具之所以强大,是因为它们可以让AI表现出代理式行为:AI不仅可以聊天,还可以通过这些功能与系统交互。出于安全考虑,客户端/主机通常要求用户在执行之前批准工具使用。工具可能具有副作用或需要进行繁重的计算。 - 提示 — 预定义的提示模板或对话工作流,帮助模型完成特定任务。提示可以视为预制的指导或对话模板,可按需插入。例如,服务器可能提供代码审查或调试错误的提示模板,结构化与模型对话的进行方式。使用提示模板可以确保AI遵循某种模式——类似于使用标准表单或脚本来确保AI遵循某种模式——这可以为该任务产生更一致的结果。提示本质上允许服务器提供最佳实践指导,从而用户或客户端无需每次从头开始创建。
这三种特征类型并不是孤立的——最终它们都只是为模型的上下文空间提供信息(通常以文本形式)。然而,区分它们有助于客户适当处理(例如,工具需要传递参数并获得用户批准,而资源则是获取并插入作为内容)。事实上,许多AI集成更侧重于工具(因为工具可以启用主动操作),但资源和提示同样重要,为提供被动的背景信息和指导。
好处和使用案例采用MCP的标准方法为AI开发带来了许多实际的好处。以下是一些采用MCP的关键应用场景及其优势:
技术细节介绍:MCP(MCP)架构设计和工作方式总的来说,MCP 的优势在于 让 AI 系统更加强大且易于构建。它为 AI 开启了更丰富的功能,比如实时上下文数据,同时减轻了开发者添加这些功能的困扰。随着 MCP 生态系统的壮大,我们很可能会见证更多富有创意的代理行为(因为模型可以发现新工具),以及更多组织会信任 AI 来整合其工作流程(得益于 MCP 提供的安全和控制功能)。
让我们更深入地探讨,了解一下MCP实际的工作原理——从客户端与服务器之间的初始握手过程到它们如何交换数据。MCP通信采用的是JSON-RPC 2.0,这是一种轻量级的远程过程调用(RPC)格式,使用JSON。这意味着每条请求和响应都是一种具有定义结构的JSON对象,如{"jsonrpc": "2.0", "method": ..., "params": ...}
,这使得它与语言无关且易于解析。支持同步请求(带有响应)和异步通知/事件。
连接与传输: MCP 设计用于 持久的有状态连接(stateful, long-lived connections),而不是单次 HTTP 调用。当 MCP 客户端启动与服务器的连接时,通常会采取两种方式中的一个:
- 基于标准输入输出流的本地传输: 如果服务器作为本地进程运行(例如命令行工具或主机启动的子进程),客户端和服务器可以通过进程的标准输入/输出流进行通信。这类似于语言服务器协议通常通过标准输入输出与语言服务器子进程通信的方式。这种方式高效,并且避免了本地工具的网络传输。
- 远程(HTTP + SSE)传输: 如果服务器是远程服务或独立运行(例如位于服务器或云环境中),MCP 可以通过 HTTP 进行通信。在这种模式下,请求可以通过 HTTP POST 发送,而 服务器发送事件(SSE)功能 则用于服务器将响应或事件推回到客户端。SSE 允许服务器可以通过 HTTP 连接流式传输数据,这对于工具输出较大或服务器需要发送增量更新(例如流式传输长文本或进度更新)的情况非常有用。在这种情况下,传输层负责可靠传输 JSON-RPC 消息。
初始化握手: 当连接建立后,首先会进行一个握手来初始化并协商能力。客户端发送一个 initialize
请求,表明它支持的 MCP 协议版本以及一些关于自身的信息。服务器则回应其自身的版本信息和它所提供的能力。这个握手确保双方使用的是兼容的 MCP 版本,并且同意一些基本设置。(例如,如果 MCP 规范有所演变,客户端可能只支持 v1.1 版本,而服务器支持 v1.2 版本——他们需要找到一个共同的基线或者优雅地处理失败。)握手还可能包括一些初始配置,例如客户端请求的“根节点”或范围。在 MCP 中,根节点通常指的是服务器的基本上下文或允许的数据集,例如文件系统的根目录路径,或 API 服务的账户范围。客户端可以提供这些信息,以便服务器了解其操作的范围或起点。
发现服务器的功能: 初始化完成后,客户端通常会查询服务器能做什么。MCP 定义了列出每种功能的标准方式:
tools/list
– 客户端调用此接口以获取服务器提供的所有工具列表,包括每个工具的名称、描述和输入模式schema等详细信息。服务器则通过返回包含工具及其定义列表的JSON对象来响应。这样,客户端(最终是LLM模型)就知道可用的操作有哪些。同样,可能有resources/list
和prompts/list
方法(或者这些信息可以在初始化响应中提供),用于枚举可用的资源端点路径和提示模板。通过这些信息,主机可以决定如何展示或利用这些功能。例如,IDE可能会向用户显示可访问资源(文件)的列表,或者客户端可能会将工具描述嵌入到LLM的系统提示中,使模型了解这些工具。- 使用工具(函数调用): 当AI模型决定调用一个工具时,该序列可能如下:模型的输出(发送给客户端)表明其希望使用特定工具(例如
get_weather
),并提供相应的参数(这可能是通过特殊响应格式或函数调用机制完成的,取决于AI)。MCP客户端(通常在用户确认后)向服务器发送一个tools/call
请求,携带工具名称和参数。例如,{"method": "tools/call", "params": {"name": "get_weather", "arguments": {"latitude": 45.5, "longitude": -122.6}}}
将请求服务器使用这些坐标调用天气工具。服务器执行相应的函数(可能涉及API调用、数据库查询等),并返回结果。结果通常以JSON-RPC响应的一部分结构化格式返回。在MCP的设计中,服务器可以在结果中表示内容类型;例如,它可能返回一个JSON对象或文本块,并附带元数据,如谁是预期受众(模型或用户)。在天气示例中,服务器可能会响应{"result": {"content": [{"type": "text", "text": "{\"temperature\": 12, \"conditions\": \"cloudy\", ...}", "annotations": {"audience": ["assistant"]}}]}}
,即以JSON文本形式返回天气数据,标记为让助手看到。客户端接收到这些信息后,将其注入到LLM上下文中(例如,就像助手看到了这些文本),使模型可以利用这些信息来形成对用户的下一个回复。这一切都在几秒钟内完成,使AI与外部数据的交互感觉无缝。 - 读取资源: 当模型或用户需要一些上下文数据时,客户端会从服务器请求一个资源。这可能是由模型提到一个资源URI或用户明确请求一个文件触发的。客户端发送一个带有资源标识符的
resources/read
(或类似)请求(例如,{"method": "resources/read", "params": {"uri": "users://123/profile"}}
)。服务器然后获取该资源(例如,查找用户123的个人资料)并返回其内容(通常是文本或结构化文本)。客户端可以将这些内容插入到与模型的对话中,通常作为提示的一部分(这样模型在回答时可以参考)。资源还可能支持部分读取或订阅功能(在日志或流数据的情况下),但本质上它们的行为就像文件系统中的读取文件——你请求内容,你得到它。 - 使用提示模板: 当主机或用户选择特定模板来引导对话时,可能会使用提示功能。比如,如果用户说“帮我调试这个错误”,服务器有一个
debug_error
提示模板,客户端可以获取该提示(它可能是一系列消息或指令),并将其插入到对话开头。在幕后,这可能是通过prompts/get
调用或在连接时直接提供完成的。提示还可能通过prompts/list
列出,使客户端UI可以向用户展示“可用策略”。一旦交付,提示将指导LLM如何构建其响应或互动。
会话和生命周期: MCP 的客户端-服务器连接保持活跃状态,允许进行多次连续交互。在完成任务后客户端可以选择关闭服务器,或者只要主应用程序保持打开状态就可以继续运行服务器。例如,当文件发生变化时,文件资源会发送通知,这些信息会被作为异步 JSON-RPC 通知发送给客户端,客户端可以据此更新上下文,或者通知用户。由于 MCP 是有状态的,这表示服务器可以根据需要在调用之间保留上下文(例如,缓存数据,或跟踪用户在外部 API 的会话)。
所有这些细节(方法、消息格式、错误处理等)都定义在 MCP 规范 中。目标是任何符合 MCP 的客户端和服务器都需要实现这些相同的方法和消息类型,以确保它们可以互相操作。技术设计使用了 JSON-RPC 和客户端-服务器模型,以确保 低耦合:AI 模型本身不直接使用 JSON-RPC;而是由客户端作为中间件进行交互。这有利于安全性和清晰性。大语言模型的接口(提示和响应)与协议分离,但 JSON API 调用是通过客户端异步进行的,两者是独立的。这种设计使得例如你可以使用支持函数调用的 OpenAI GPT-4 作为 MCP 的宿主——客户端只需将模型的函数调用映射到 MCP tools/call
请求,反之亦然进行映射。模型不需要知道 MCP 存在,客户端会处理相关事宜。
总之,MCP的工作流程是:建立连接(打开通道,握手)→ 发现(服务器能做什么?)→ 使用(模型或用户请求资源或工具,服务器返回结果)→ 按需重复使用 → 关闭(关闭连接)。因此开发人员可以专注于高层次的逻辑(提供什么工具或数据),而无需关注网络细节,在整个过程中,请求格式处理和响应处理的繁重工作由MCP客户端和服务器库完成。
使用指南:使用MCP Python SDK(软件开发工具包)使用 Python SDK 是获取 MCP 实手经验最简单的方法之一,它是 Python 中的协议参考实现。此 SDK 允许你创建自己的 MCP 服务器(或客户端),并尝试与 AI 模型进行连接。在本节中,我们将介绍如何设置 SDK,构建并运行一个简单的 MCP 服务器。
安装MCP Python SDK 可通过 PyPI 下载。使用 pip 命令即可轻松安装。建议包含 “cli” 附加包,从而获得测试及运行服务器的命令行工具。
pip install uv
pip install "mcp[cli]"
这将安装 mcp
包及其相关工具。(或者,你可以使用 pip install mcp
安装核心功能,或者你可以按照官方文档中的说明使用该项目的环境工具 uv
。)
确保你安装了Python 3.10+,这是SDK所要求的版本。安装完成后,你可以在终端中运行mcp --help
来查看的可用命令。
让我们用Python搭建一个基本的MCP服务器。这个服务器将展示两种功能——一个工具和一种资源——以展示它们是如何定义的。
示例: 我们将创建一个MCP服务器(server.py),进行简单的加法运算(工具)并提供问候信息(资源)。
# 这是 server.py 文件,引入了 FastMCP 模块
from mcp.server.fastmcp import FastMCP
# 初始化一个名为 "演示服务器" 的 MCP 服务器实例
mcp = FastMCP("演示服务器")
# 定义一个工具函数(两个整数的加法)
@mcp.tool()
def add(a: int, b: int) -> int:
"""返回两个整数的和。"""
return a + b
# 定义一个资源函数(个性化问候)
@mcp.resource("问候://{name} (个性化问候)")
def get_greeting(name: str) -> str:
"""返回给定名字的问候消息。"""
return f"你好,{name}!"
在这个代码中,我们导入了 FastMCP
——一个高层次的类库,使得搭建服务器变得简单。我们创建了一个名为 "Demo Server"
的 mcp
服务器实例对象。然后我们使用 SDK 中提供的装饰器来注册工具和资源。
@mcp.tool()
装饰器将add
函数转换为一个 MCP 工具。默认情况下,工具的名称将与函数名(add
)相同,SDK 使用类型提示和文档字符串自动生成输入参数模式和描述。此工具只是返回两个整数的和。@mcp.resource("greeting://{name}")
装饰器将get_greeting
注册为一个由 URI 模式标识的资源。字符串"greeting://{name}"
表示此资源可以通过带有动态部分(name)的 URI 方案greeting://
访问。如果客户端稍后请求greeting://Alice
,此函数将被调用,传入name="Alice"
参数,并返回"Hello, Alice!"
。文档字符串可以用作该资源的说明文档。- 现在点击本地主机,您会看到 MCP 检查器。
就这样——我们有一个功能正常的MCP服务器,有一个工具和一个资源。你可以用类似的方式添加更多的工具或资源,或者用@mcp.prompt()
定义提示模板等等。
运行此服务器有多种选择:你可以选择不同的方式。
- 开发模式(Inspector 模式): MCP SDK 包含一个名为 MCP Inspector(MCP 检查器)的开发工具,它可以模拟客户端并让你与服务器进行交互。可以通过运行
mcp dev server.py
来启动它,并请确保在那之前已安装了 node。
- 这将启动你的
server.py
程序,并打开一个交互式 UI,在那里你可以测试调用add
函数或工具,或读取greeting://...
资源链接。这对于快速测试和调试来说非常方便,试试看。
- 直接执行: 您也可以直接运行服务器作为一个独立进程。例如,只需执行您的脚本:
python server.py
- 在幕后,由于使用了
FastMCP
,它会自动运行事件循环并等待客户端连接(默认使用stdio传输)。我们也可以在if __name__ == "__main__":
块中显式调用mcp.run()
来启动服务器。之后,服务器将等待MCP客户端通过stdio连接。 - 或者,SDK提供了一个快捷方式:
mcp run server.py
这将执行您的服务器脚本并保持其开放,以便客户端可以使用。 - 与AI主机集成: 要看到真正的魔法,您可以将该服务器连接到兼容MCP的AI客户端。如果您有Claude Desktop,可以安装服务器,使Claude可以使用它。例如:
mcp install server.py --name "Demo Server"
- 这将把您的服务器注册到Claude Desktop(
--name
参数给它一个友好的名称)。然后,在Claude的界面中,您将能够启用“Demo Server”作为数据源。Claude可以调用add
工具或读取greeting
资源作为对话的一部分。(通常,您会提示Claude使用类似“使用Demo Server计算2和3的和”的话,它会通过MCP调用工具。) - 如果您没有Claude,其他客户端正在出现。例如,您可以编写一个小型MCP客户端脚本,连接到
server.py
并发出tools/call
或resources/read
,但这超出了我们当前的讨论范围。关键是现在任何MCP客户端都可以与服务器交互。
这个简单的演示只是稍微展示了一些功能。使用 Python SDK,你可以构建更复杂的服务器:连接到外部 API、处理数据库查询,甚至如连接硬件设备。SDK 支持异步函数,就像我们在之前的天气例子中那样,并提供用于流媒体处理结果、处理图像、管理认证等的工具。还有 TypeScript、Java 和 Kotlin 的 SDK,具有类似的功能,使开发者能够根据自己的技术环境来实现 MCP 服务。
MCP 是相对较新的 AI 工具领域参与者,自然会有人想知道它与其他整合外部数据或功能的方法相比有何独特之处。这里来看看一些相关概念,比如 MCP 的独特之处。
下面是一些总结性的观点。
在这次深入探讨中,我们看到了MCP如何运作,其组件(主机、客户端、服务器),以及它支持的不同功能(资源、工具、提示)。我们展示了技术流程,实际上,MCP是一个干净的JSON-RPC协议,任何平台都可以实现。Python SDK示例展示了创建MCP连接器就像编写几个带有装饰器的函数一样简单,这些功能可以立即被任何MCP兼容的人工智能使用。在将MCP与其他方法进行比较时,我们发现虽然有其他方法将工具插入到AI中,但MCP的开放性和互操作性设计使它在众多方法中脱颖而出,成为不断增长的生态系统的核心。
MCP 仍在持续发展(截至撰写之时,它正处于活跃开发阶段,并拥有一个开源社区,但其核心理念已经在 AI 社区中引起了共鸣。主要的集成开发环境(IDE)和助手已经开始采用 MCP,开发人员积极贡献新服务器。如果你正在构建 AI 应用程序,那么关注 MCP 甚至尝试使用它都是值得的。你可能会发现,与其重新发明另一种集成方式,不如利用这个“AI 的 USB-C”将你的模型与所需的一切连接起来。最终结果是,这些 AI 系统会更情境感知、功能强大且与外界紧密相连——这是迈向更智能、更实用 AI 的关键一步。
参考文献Introducing the Model Context Protocol \ Anthropic
模型上下文协议(MCP)介绍 — 开始使用MCPmodelcontextprotocol.io什么是模型上下文协议(MCP):详细解释 —— DEV 社区。简单来说,它类似于我们常用的网络或使用简单邮件传输协议进行消息传递的协议。
如何将模型上下文协议工具与语义内核集成:一步一步的指南 | 语义内核…这篇帖子将介绍如何使用模型上下文协议(MCP)工具与语义内核结合。模型上下文协议(MCP)是一种…[模型上下文协议(MCP) — NSHipster](https://nshipster.com/model-context-protocol/#: 请求和响应都是经过编码的,发送事件传输)
模型上下文协议(Model Context Protocol)一个开放协议,使大语言模型应用程序能与外部数据源和工具无缝集成:更多详情,请访问GitHub: github.com/modelcontextprotocol mcp上下文协议SDK pypi.org模型上下文协议(MCP)是由Anthropic开发的 — WorkOS
感谢你加入我们社区在你走之前:
- 记得给作者鼓掌👏并关注他/她
- 关注我们:X | LinkedIn | YouTube | Newsletter | Podcast | Differ
- 试试CoFeed,以最智能的方式掌握最新科技资讯 🧪
- 在Differ免费启动自己的AI博客 🚀
- 加入我们的内容创作者Discord社区 🧑💻
- 更多内容,请访问 plainenglish.io 和 stackademic.com
共同學習,寫下你的評論
評論加載中...
作者其他優質文章