MCP协议全解：Anthropic定义的Agent工具标准

可视化演示

展示MCP基于JSON-RPC 2.0的Client-Server通信流程及Resources、Tools、Prompts三大核心原语的网络拓扑。

设计理念：一根USB线打通千军万马

你抽屉里是不是堆满了各种充电线？手机、耳机、充电宝各用各的线，每次出门都要带一大把。这就是没有统一标准造成的混乱。AI 世界也曾经如此：模型想调用搜索、数据库、办公软件，每个工具都要单独做适配，换个模型又得重来一遍。MCP 要做的，就是给 AI 世界发明一根“USB 线”，让模型和工具都能统一插拔。

MCP 全称 Model Context Protocol，中文叫“模型上下文协议”，由 Anthropic 提出。它的核心使命，是把“模型”和“工具”从紧紧捆绑的状态中解放出来。过去模型调用工具是“点对点”的适配，而现在通过 MCP，工具方只需要实现一个服务器，模型方通过客户端按统一协议对接，两边都可以独立演进、互不牵连。

在 MCP 架构里，工具提供方实现一个“MCP 服务器”，把自己能提供的资源、动作和模板声明出来；模型应用方通过“MCP 客户端”连上去，按统一协议完成发现与调用。OpenAI、Google 等模型厂商也开始兼容 MCP，意味着同一套工具可以服务不同品牌的模型，真正实现“一次接入，处处运行”。

就像 USB-C 一统手机充电口，MCP 让 AI 开发者不必再为每个模型重写工具链接，真正实现“一线通吃”。

核心原语：三个万能插头

USB 世界里，有数据线、充电线、视频线，各有各的接口形态。MCP 世界里也有三类标准化的“插头”，它们被称为核心原语：Resources、Tools、Prompts。三种原语各管一摊，组合起来才能让 Agent 既能“看”、又能“做”、还知道“怎么做”。

Resources 代表可被模型读取的外部数据，比如文件、数据库条目、网页内容。Tools 代表可执行的函数或动作，比如“查天气”“发邮件”“下单”。Prompts 则是可复用的提示模板，把常见任务的指令结构化封装，方便开发者快速拼装 Agent。三者共同组成 MCP 的能力面，并通过统一协议传输。

在实际使用中，Resources 为 Agent 提供“上下文”，Tools 让它有能力改变世界，Prompts 让它的行为模式可以沉淀复用。它们都有唯一的命名空间标识，客户端可以通过协议发现服务器上有哪些资源、工具和提示，无需预先写死。

三个“插头”各司其职：数据插头让 Agent 获得信息，执行插头让它采取行动，指令插头让它快速复用经验。只有三合一，Agent 才真正完整。

通信流程：点单、下单、上菜

去餐厅吃饭，你告诉服务员想吃什么，服务员转达厨房，厨房做好后端上菜。MCP 的通信就是这种请求-响应模式，只不过服务员换成了 JSON-RPC 2.0 协议。每一次调用都是一条消息，带着明确的“单号”和“菜名”，保证双方不会搞混。

MCP 基于 JSON-RPC 2.0，这是一种轻量级的远程调用协议。所有消息都是键值对形式的 JSON 对象，包含协议版本、方法名、参数和消息 ID。客户端发送请求，服务器处理后返回结果。整个过程简洁、可调试。

典型流程包括：客户端先发送 initialize 消息握手，确认双方支持的协议版本；然后通过 tools/list 发现服务器上有哪些工具；最后用 tools/call 发起实际调用。每一步都有对应的响应，任何异常都有统一的错误码返回。

就像服务员接单、上菜都要看单号，MCP 的 id 保证了“谁点的菜归谁”，即使同时发起多个请求也不会乱。

协议架构：接线盒的里里外外

一个接线盒里，进线和出线各走各的通道，盒子规范决定了两边怎么对接。MCP 的架构里也有两个固定角色：客户端和服务器。客户端是模型应用侧，负责发起会话、调用工具；服务器是工具侧，负责注册能力、响应请求。

客户端与服务器之间的连接，可以通过两种典型传输方式实现。本地场景用 stdio，也就是标准输入输出传输，两个进程直接对话；远程场景用 Streamable HTTP，让工具以服务形式暴露给网络上的客户端。无论哪种，接口层面保持一致。

MCP 会话有明确的生命周期。开始时，客户端发送 initialize 做握手，服务器回复协议版本和支持的能力；随后进入正常的工具发现、调用阶段；最后可以主动断开。这种设计让连接状态清晰可控，也方便做权限管理和审计。

有了这个“接线盒”，无论你把线插在本地电脑还是远程服务器，接口规格都一样。换环境不用换接线方式，这就是协议架构的价值。

生态标准：从一家发声到众厂响应

某家手机厂率先发布了一个开放接口标准，其他品牌纷纷跟进，最后整个行业都采用，用户买任何配件都能通用。MCP 就是 AI 界的这个“接口标准”。它由 Anthropic 在 2024 年开源并推广，随后迅速得到生态响应。

OpenAI、Google 等原本各有生态的厂商也宣布支持 MCP。之所以能形成事实标准，核心在于“解耦”的收益：模型厂商不需要再为每家工具做适配，工具厂商也不需要针对每个模型写 SDK。一次开发、全网通用，整个产业链都受益。

MCP 的设计是开放的，任何人都可以实现自己的 MCP 服务器或客户端。就像 USB 标准虽然由某公司发起，但最终成为行业公共品。开放治理、多方参与，让大家对它更有信心，生态飞轮一旦转起来就很难停下。

USB 成为通行标准后，配件厂和手机厂都获益。MCP 让 AI 产业链上下游都吃到“兼容”的红利，这就是标准的力量。

Agent 集成：让 Agent 学会用插头

Agent 就像拿着“万能插头”的外卖员，接单、取餐、送餐，每一步都要调用不同系统。MCP 给了它一套标准插脚，让它能随时接入新工具，而不必关心每个工具背后的实现细节。

在 Agent 工作流中，MCP 客户端负责与各个 MCP 服务器对话。Agent 决策层根据任务选择工具，通过 tools/list 发现可用能力，再通过 tools/call 调用具体动作。整个过程就像点单、取餐，分工明确、流程清晰。

MCP 还支持多工具编排。一个 Agent 可以同时连接多个服务器，把“查天气”“订机票”“查酒店”组合成一次完整规划。更棒的是，工具支持动态发现，Agent 在运行时就知道了什么可用，而不是把调用链写死在代码里。

标准插脚让 Agent 面对新任务时，只是多插一根线，而不是重写整个电路。这也是 MCP 在 Agent 架构中愈发核心的原因。

实践入门：亲手做一根线

自己动手做一根 USB 线并不难——买接头、焊接、测试。MCP 入门也类似，基于官方 SDK，几十行代码就能搭建一个实实在在的 MCP 服务器。理论上你只需要三步：定义服务名、注册工具、处理请求。

MCP 官方提供 Python、TypeScript 等 SDK。一个 MCP 服务器的核心逻辑很简单：初始化时声明自己的名字和协议版本；提供 tools/list 返回工具清单；收到 tools/call 后执行对应函数并返回结果。客户端则负责发送请求并展示返回内容。

入门建议先用本地 stdio 传输，在自己电脑的 Python 脚本里跑通；熟悉后再升级到 Streamable HTTP，部署成远程服务。任何时候都要考虑安全：只暴露必要工具、对输入做严格校验，避免恶意参数导致命令注入或数据泄露。

亲手做一根“线”，你才会真正理解插头标准的价值。等到 Agent 时代全面到来，你就是那个掌握“造线”手艺的人。

AI 应用场景

Python 演示

# 一个极简 MCP 风格工具服务器class MCPServer:    def __init__(self, name):        self.name = name        self._tools = {}     def register_tool(self, name, fn):        self._tools[name] = fn     def handle(self, req):        method = req.get("method")        params = req.get("params", {})        msg_id = req.get("id")        if method == "initialize":            return {"jsonrpc": "2.0", "result": {"serverName": self.name,                    "protocolVersion": "1.0"}, "id": msg_id}        if method == "tools/list":            tools = [{"name": k} for k in self._tools]            return {"jsonrpc": "2.0", "result": {"tools": tools}, "id": msg_id}        if method == "tools/call":            tool_name = params.get("name")            args = params.get("arguments", {})            fn = self._tools.get(tool_name)            if fn is None:                return {"jsonrpc": "2.0",                        "error": {"code": -32601, "message": "tool not found"},                        "id": msg_id}            result = fn(**args)            return {"jsonrpc": "2.0", "result": result, "id": msg_id}        return {"jsonrpc": "2.0", "error": {"code": -32601}, "id": msg_id}  mcp = MCPServer("weather-mcp")  def get_weather(city: str) -> str:    return f"{city}: 晴转多云, 25C"  mcp.register_tool("get_weather", get_weather) req = {"jsonrpc": "2.0", "id": 1, "method": "initialize", "params": {}}print(mcp.handle(req))req2 = {"jsonrpc": "2.0", "id": 2,        "method": "tools/call",        "params": {"name": "get_weather", "arguments": {"city": "北京"}}}print(mcp.handle(req2))

1. self._tools = {}工具注册表，保存工具名到处理函数的映射。
2. def handle(self, req)统一入口，所有 JSON-RPC 请求都从这进入。
3. if method == "initialize":处理握手消息，返回服务器名和协议版本。
4. if method == "tools/call":取出工具名和参数，反射调用对应函数。
5. result = fn(**args)实际执行工具函数，并拿到返回值。
6. print(mcp.handle(req2))模拟客户端发送工具调用请求并打印结果。

常见误区

面试题