全景解读 MCP 协议
一、什么是 MCP 协议?
1.1 MCP 的定义与作用
模型上下文协议(Model Context Protocol,MCP) 是一种专为大语言模型(LLM)设计的开放通信协议。它的核心使命是让 LLM 应用与外部数据源和工具无缝连接。简单来说,MCP 是一个标准化的「桥梁」,连接 LLM 和各种外部资源,让它们在安全、可控的环境下协作。
举个例子,当你在用一个 AI 编程助手时,它需要读取你的代码文件、调用 API 获取数据,或者生成代码片段。这个时候,MCP 就像一个「通用翻译官」,帮助 AI 助手背后的 LLM 理解外部世界,并与之互动。类似的场景中包括:
- AI 驱动的 IDE:让代码补全工具访问你的项目文件。
- 智能聊天机器人:从数据库或网络获取实时信息。
- 自定义 AI 工作流:将多个工具和数据源组合起来。
1.2 为什么需要 MCP?
随着 LLM(如 ChatGPT、Claude 等)的普及,开发者们发现,LLM 本身很强大,但它们有一个局限:无法直接访问外部数据或执行操作。比如,LLM 不能直接打开你的文件、查询数据库或调用 API。你可以使用一些库或框架(比如 Langchain、smolagents 等)来开发自己的工作流或者 Agent,来让 LLM 使用这些外部资源或者工具,但这种方式存在一些问题:
- 重复劳动:每个应用都需要重新实现与外部数据的连接逻辑。
- 缺乏标准:不同的工具和数据源通信方式不统一,集成成本高。
- 安全隐患:直接暴露数据或工具给 LLM,容易引发隐私泄露或误操作。
MCP 的出现,正是为了解决这些痛点。它提供了一个统一的框架,让 LLM 应用以标准化、安全的方式获取上下文和能力。有了 MCP 这种模块化协作方式,开发者无需从头开始构建整个系统,只需遵循协议,开发对应的工具插件,就能快速构建强大的 AI 应用。
1.3 MCP 与其他协议的类比
为了更好地理解 MCP,我们可以用一个类比:语言服务器协议(LSP)。LSP 是为编程语言和 IDE 设计的标准协议,让代码编辑器(如 VS Code)能与各种语言的语法检查、补全工具通信。
在 LSP 协议出现之前,每当一个新的编程语言出现时,IDE 的开发者都需要为该语言编写专门的插件或扩展,以便提供代码补全、语法检查、跳转到定义等功能。这样做同样存在重复劳动、维护困难、生态割裂的问题。
为了解决这些问题,以为首微软的一些企业提出了 LSP 协议,目标是将语言支持的实现从 IDE 中解耦出来,放到独立的语言服务器中。这样,IDE 只需要实现对 LSP 协议的支持,就可以与任何实现了 LSP 协议的语言服务器进行通信,从而获得对该语言的全面支持。
而 MCP 之于 AI Agent,就恰如 LSP 之于 IDE:
- LSP:IDE 和编程语言的「翻译官」,提供语法高亮、补全等功能。
- MCP:LLM 和外部世界的「翻译官」,提供数据、工具和交互模板。

二、MCP 的核心概念
2.1 客户端 - 宿主 - 服务器架构
MCP 采用了一种 客户端 - 宿主 - 服务器(Client-Host-Server) 的架构。让我们拆解一下:
- 宿主(Host):运行 LLM 的应用程序,比如一个 AI 聊天工具或编程助手。它是「大脑」,负责协调一切。
- 客户端(Client):宿主中的「使者」,负责与外部服务器通信。宿主可以创建多个客户端,每个客户端连接一个服务器。
- 服务器(Server):提供数据和功能的外部服务,比如文件系统、数据库或 API。
就好比你在餐厅(宿主)点餐,服务员(客户端)会去厨房(服务器)取食物。餐厅可以派多个服务员去不同的厨房,分别拿披萨、饮料等。MCP 的架构也是如此,宿主通过客户端从多个服务器获取所需资源。
下面是一个简单的架构图:

2.2 MCP 的三大原语:资源、提示、工具
MCP 定义了三种核心功能(称为「原语」),它们是 LLM 与外部世界交互的基础:
- 资源(Resources)
- 作用:提供数据给 LLM,比如文件内容、数据库记录。
- 特点:只读,不产生副作用,类似 REST API 的 GET 请求。
- 例子:读取代码文件
main.py,返回其内容。
- 提示(Prompts)
- 作用:提供模板化的消息,指导 LLM 如何响应用户。
- 特点:由用户触发,类似预设的对话模板。
- 例子:输入「检查这段代码」,返回一个代码审查提示。
- 工具(Tools)
- 作用:让 LLM 执行操作,比如计算、查询 API。
- 特点:可写,产生副作用,类似 REST API 的 POST 请求。
- 例子:调用天气 API,返回当前温度。
这三大原语各有分工,满足不同的需求。可以用一个表格总结它们的控制方式:
| 原语 | 控制者 | 描述 | 示例 |
|---|---|---|---|
| 资源 | 应用控制 | 提供上下文数据 | 文件内容、API 响应 |
| 提示 | 用户控制 | 定义交互模板 | 斜杠命令、菜单选项 |
| 工具 | 模型控制 | 执行具体操作 | 计算器、搜索功能 |
2.3 JSON-RPC 2.0:MCP 的通信基石
MCP 不同组件之间如何通信呢?需要有一套类似远程过程调用(RPC)的协议来进行规范。所谓的远程过程调用,本质上就是:结构化数据 + 网络传输。
- 结构化数据:MCP 的通信层使用了 JSON-RPC 2.0 这种协议,它的核心思想是用 JSON 格式的消息,在客户端和服务器之间传递请求和响应。MCP 使用该协议定了三种结构化的消息类型,所有的通信内容都逃不出这三种格式。
- 请求(Request):发起一个操作,期待响应。例如:「请给我文件内容。」
- 响应(Response):回复请求的结果。例如:「这是文件内容。」
- 通知(Notification):单向消息,不需要回复。例如:「文件已更新。」
- 网络传输:而 MCP 网络传输层,目前提供了两种选择
- stdio:通过标准输入和标准输出进行通信
- HTTP with SSE:带有服务器发送事件 (Server-Sent Events, SSE) 的 HTTP
下一节我们会更详细地介绍。
三、MCP 协议的工作原理
3.1 生命周期:从初始化到关闭
MCP 的通信有一个清晰的生命周期,分三个阶段:
- 初始化(Initialization)
- 客户端和服务器建立连接,协商协议版本和支持的功能。
- 客户端发送
initialize请求,服务器回复支持的能力。
- 操作(Operation)
- 双方根据协商结果交换消息,比如请求资源、调用工具。
- 关闭(Shutdown)
- 一方(通常是客户端)关闭连接,结束会话。
生命周期流程图:

3.2 能力协商:客户端与服务器的「握手」
在初始化阶段,客户端和服务器会进行「能力协商」,类似于两人见面时互相介绍自己能做什么,协商结果决定会话中可用功能,确保双方理解彼此的能力。用一个例子来理解:
- 客户端(例如 AI 编程助手)连接到一个代码仓库服务器。
- 客户端告诉服务器:「我支持资源订阅和工具调用。」
- 服务器告诉客户端:「我支持代码搜索和代码片段生成。」
- 现在,客户端就可以使用代码搜索和代码片段生成功能了,并且可以订阅代码仓库的更新,以便在代码发生变化时及时收到通知。
3.3 消息类型:请求、响应、通知
MCP 客户端和服务器之间的所有消息都遵循 JSON-RPC 2.0 规范。该协议定义了三种基本类型的消息:
| 类型 (Type) | 描述 (Description) | 要求 (Requirements) |
|---|---|---|
请求(Requests) |
用于启动操作的消息 | 必须包含唯一的 ID 和方法名称 |
响应(Responses) |
用于回复请求的消息 | 必须包含与请求相同的 ID |
通知(Notifications) |
单向消息,无需回复 | 必须不包含 ID |
响应 (Responses) 进一步细分为 成功结果 (successful results) 或 **错误 (errors)**。 结果可以遵循任何 JSON 对象结构,而错误必须至少包含错误代码和消息。
3.4 传输机制
MCP 目前定义了两种用于客户端 - 服务器通信的标准传输机制可供选择:stdio 和 HTTP with SSE。官方建议客户端应该尽可能支持 stdio。具体的实现中,也可以自定义传输机制,比如可以通过任何支持双向消息交换的通信通道来实现,但必须支持 MCP 定义的 JSON-RPC 消息格式和生命周期要求。
3.4.1 Stdio
stdio 就像是客户端和服务器通过命令行进行通信。 客户端启动服务器进程,然后通过标准输入 (stdin) 向服务器发送消息,服务器通过标准输出 (stdout) 将响应返回给客户端。

3.4.2 HTTP with SSE
HTTP with SSE 就像是客户端和服务器通过网页进行通信。 客户端首先通过 SSE 建立一个长连接,服务器会返回一个用于发送消息的 HTTP POST 端点。 然后,客户端通过 HTTP POST 向服务器发送消息,服务器通过 SSE 将消息推送给客户端。
在 SSE 传输中,服务器作为独立进程运行,可以处理多个客户端连接。服务器 必须 提供两个端点:
- 一个 SSE 端点,供客户端建立连接并接收来自服务器的消息
- 一个常规 HTTP POST 端点,供客户端向服务器发送消息
四、 MCP 的功能特性
4.1 服务器功能
服务器是 MCP 的「供应者」,提供三种主要原语:
- **提示 (Prompts)**:预定义的模板或指令,用于指导语言模型交互
- **资源 (Resources)**:结构化数据或内容,为模型提供额外的上下文
- **工具 (Tools)**:可执行函数,允许模型执行操作或检索信息
每个原语都可以概括为以下控制层次结构:
| 原语 (Primitive) | 控制 (Control) | 描述 (Description) | 示例 (Example) |
|---|---|---|---|
| 提示 (Prompts) | 用户控制 (User-controlled) | 用户选择调用的交互式模板 | 斜杠命令、菜单选项 |
| 资源 (Resources) | 应用控制 (Application-controlled) | 客户端附加和管理的上下文数据 | 文件内容、git 历史记录 |
| 工具 (Tools) | 模型控制 (Model-controlled) | 暴露给 LLM 以执行操作的函数 | API POST 请求、文件写入 |
4.1.1 资源(Resources)
模型上下文协议 (MCP) 提供了一种标准化的方式,供服务器向客户端公开资源。 资源允许服务器共享为语言模型提供上下文的数据,例如文件、数据库架构或特定于应用程序的信息。 每个资源都由 URI 唯一标识。应用程序可以根据需要选择如何使用这些资源,比如,资源可以通过各种方式呈现给用户,例如树状视图、列表视图等。

4.1.2 提示(Prompts)
提示允许服务器提供结构化消息和指令,以便与语言模型进行交互。 客户端可以发现可用的提示、检索其内容并提供参数以自定义它们。提示可以通过各种方式呈现给用户,例如斜杠命令、菜单选项等。

4.1.3 工具(Tools)
工具使模型能够与外部系统进行交互,例如查询数据库、调用 API 或执行计算。 每个工具都由名称唯一标识,并包含描述其架构的元数据。语言模型可以根据其理解和用户的提示自动调用这些工具。需要注意安全问题,确保始终有人参与其中,并能够拒绝工具调用。

4.2 客户端功能
客户端是 MCP 的「请求者」,提供两种功能:
4.2.1 根目录(Roots)
模型上下文协议 (MCP) 提供了一种标准化的方式,供客户端向服务器公开文件系统「根目录」。 根目录定义了服务器可以在文件系统中运行的边界,允许它们了解它们可以访问哪些目录和文件。 服务器可以从支持客户端请求根目录列表,并在该列表更改时接收通知。
在具体实现中,MCP 中的根目录通常通过工作区或项目配置界面公开。例如,实现可以提供一个工作区/项目选择器,允许用户选择服务器应该有权访问的目录和文件。 这可以与来自版本控制系统或项目文件的自动工作区检测相结合。

4.2.2 采样(Sampling)
模型上下文协议 (MCP) 提供了一种标准化的方式,供服务器通过客户端从语言模型请求 LLM 采样(「完成」或「生成」)。 此流程允许客户端维护对模型访问、选择和权限的控制,同时使服务器能够利用 AI 功能——无需 API 密钥。 服务器可以请求基于文本或图像的交互,并可选择在其提示中包含来自 MCP 服务器的上下文。需要注意安全问题,确保始终有人参与其中,并能够拒绝采样请求。
MCP 中的采样允许服务器通过使 LLM 调用发生在「嵌套 (nested)」在其他 MCP 服务器功能内部来实现代理行为。在具体的实现中,可以自由地通过任何适合其需求的界面模式公开采样——协议本身不强制执行任何特定的用户交互模型。

4.3 实用工具
MCP 还定义了一些增强功能,不详细介绍了:
- Ping:检测连接是否存活。
- 取消(Cancellation):中止正在进行的请求。
- 进度(Progress):跟踪任务进度。
- 日志记录(Logging):记录操作日志。
- 自动补全(Completion):提供参数建议。
- 分页(Pagination):分批返回大结果集。
五、安全与信任原则
值得强调的是,MCP 的强大功能带来了安全挑战,因此它在各个组件、流程的定义中,始终强调以下原则:
- 用户同意:所有数据访问和操作需用户明确同意。
- 数据隐私:未经许可不得泄露用户数据。
- 工具安全:工具调用需用户确认。
- 采样控制:LLM 生成内容需用户审核。
实现协议的开发者需在应用中实现同意流程,确保安全性和透明度。
六、MCP Python SDK 开发实战
6.1 安装与快速上手
安装 MCP SDK:
pip install mcp
快速创建服务器:
from mcp.server.fastmcp import FastMCPmcp = FastMCP("Demo")@mcp.tool()def add(a: int, b: int) -> int: return a + bif __name__ == "__main__": mcp.run()
运行:
python server.py
6.2 核心组件
- 服务器:
FastMCP类。 - 资源:用
@mcp.resource装饰器定义。 - 工具:用
@mcp.tool装饰器定义。 - 提示:用
@mcp.prompt装饰器定义。
6.3 示例项目
6.3.1 Echo Server
from mcp.server.fastmcp import FastMCPmcp = FastMCP("Echo")@mcp.resource("echo://{msg}")def echo_resource(msg: str) -> str: return f"Echo: {msg}"@mcp.tool()def echo_tool(msg: str) -> str: return f"Tool Echo: {msg}"
6.3.2 SQLite Explorer
import sqlite3from mcp.server.fastmcp import FastMCPmcp = FastMCP("SQLite Explorer")@mcp.tool()def query_db(sql: str) -> str: conn = sqlite3.connect("test.db") return str(conn.execute(sql).fetchall())
6.4 高级用法
编写客户端:
from mcp.client.stdio import stdio_clientfrom mcp import ClientSessionasync def run(): async with stdio_client(command="python server.py") as (read, write): async with ClientSession(read, write) as session: await session.initialize() result = await session.call_tool("add", {"a": 2, "b": 3}) print(result) # 输出 5if __name__ == "__main__": import asyncio asyncio.run(run())
学AI大模型的正确顺序,千万不要搞错了
🤔2026年AI风口已来!各行各业的AI渗透肉眼可见,超多公司要么转型做AI相关产品,要么高薪挖AI技术人才,机遇直接摆在眼前!
有往AI方向发展,或者本身有后端编程基础的朋友,直接冲AI大模型应用开发转岗超合适!
就算暂时不打算转岗,了解大模型、RAG、Prompt、Agent这些热门概念,能上手做简单项目,也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料,手把手帮你快速入门!👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型(GPT、文心一言等)特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架(LangChain等)实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块,看似清晰好上手,实则每个部分都有扎实的核心内容需要吃透!
我把大模型的学习全流程已经整理📚好了!抓住AI时代风口,轻松解锁职业新可能,希望大家都能把握机遇,实现薪资/职业跃迁~
这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐



所有评论(0)