本文导读MCPModel Context Protocol是 Anthropic 于 2024 年 11 月开源的标准协议为 LLM 应用与外部数据源、工具之间提供统一的连接标准。本文从协议定义讲起依次拆解 Host-Client-Server 三方架构、Tools/Resources/Prompts 三大原语、JSON-RPC 2.0 通信机制与生命周期配合两个可运行的代码实战最后客观呈现行业格局与争议——包括 Playwright 团队公开建议编码 Agent 用 CLI 而非 MCP的最新动向并给出工程师视角的选型建议。适用读者正在评估或落地 MCP 的后端/平台工程师构建 AI Agent 与工具链的开发者关注 LLM 应用架构的技术负责人。关键词MCP、Model Context Protocol、JSON-RPC、Agent 工具调用、FastMCP、stdio、Streamable HTTP一、MCP 是什么为终结 M×N 适配爆炸而生的开放协议Model Context Protocol简称 MCP是 Anthropic 于 2024 年 11 月发布并开源的标准化协议目标是给 LLM 应用与外部数据源、工具之间建立一个统一的连接规范。截至本文写作时2026 年 7 月底协议规范仍在持续迭代正式版本修订仍在按节奏发布——这是一个活跃维护中的开放标准而非一次性的技术宣传。在 MCP 出现之前AI 应用接入外部工具遵循M 选 N的组合模式M 个 AI 应用乘以 N 个工具每个组合都要单独写适配。5 个应用接 10 个工具就是 50 份适配代码任何一端升级另一端都要跟着改。组合数随生态规模呈乘积级增长维护成本压垮过所有认真做过工具集成的团队。MCP 把这个乘积压成了和工具方实现一次 MCP Server所有支持协议的 AI 端都能调用AI 端实现一次客户端协议就能调用所有 Server。M×N 变成 MN。MCP 出现前M 个 AI 应用 × N 个工具 M×N 份适配 应用A ──专用适配── 工具1 应用A ──专用适配── 工具2 应用B ──专用适配── 工具1 ← 每条线都是独立维护负担 应用B ──专用适配── 工具2 MCP 出现后M N 份协议实现 应用A ─┐ ┌─ 工具1MCP Server 应用B ─┼── 统一协议 ────┼─ 工具2MCP Server 应用C ─┘ └─ 工具3MCP Server社区里最流行的类比是 USB-C。USB-C 出现之前显示器用 HDMI、硬盘用 USB-A、手机用 Micro-USB抽屉里躺着一捆转接线USB-C 统一接口之后一根线走天下。MCP 想做的事完全一样定义一个所有人共同遵守的物理形态与握手协议让接得上不再是问题开发者把精力留给用得好。需要强调一点MCP 是开放标准规范、SDK 与参考实现都在开源仓库中任何厂商都可以实现不与某家公司的商业产品绑定。这一点是后面讨论行业格局的前提。二、核心架构Host、Client、Server 三方拓扑MCP 的架构里有三个角色职责边界划得很清楚角色本质典型例子核心职责Host运行 LLM 的应用程序Claude Desktop、Cursor、各类支持 MCP 的 IDE 与 Agent 框架面向用户内含一个或多个 Client负责整体编排与安全策略ClientHost 内部与单个 Server 的一对一连接器Host 内嵌的协议客户端模块维护与 Server 的会话状态、能力协商、消息路由Server提供工具、资源、提示模板的服务端文件系统 Server、GitHub Server、数据库 Server、Slack Server暴露能力原语执行实际操作并返回结果三个角色里有几个容易被忽略的细节。第一Client 与 Server 严格一对一。一个 Client 只连接一个 Server不存在一个 Client 复用多条连接。如果 Host 需要同时接入文件系统、GitHub、数据库三个 ServerHost 内部就要有三个 Client 实例各管各的连接。这个设计牺牲了一点资源效率换来了状态隔离与故障隔离——某个 Server 崩溃只影响对应的 Client。┌─────────────────────── Host运行 LLM 的应用───────────────────────┐ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ Client1 │ │ Client2 │ │ Client3 │ LLM / 编排逻辑 │ │ └────┬────┘ └────┬────┘ └────┬────┘ │ └────────┼─────────────┼─────────────┼─────────────────────────────────┘ │一对一 │一对一 │一对一 ┌────▼────┐ ┌────▼────┐ ┌────▼────┐ │ 文件系统 │ │ GitHub │ │ 数据库 │ │ Server │ │ Server │ │ Server │ └─────────┘ └─────────┘ └─────────┘第二Host 是安全策略的执行点。MCP 规范明确要求 Host 控制 Server 能获得什么信息、能执行什么操作。用户授权、数据过滤、工具白名单都发生在 Host 层而不是无差别地透传给所有 Server。工程上意味着写一个 MCP Server 不等于获得了任意权限最终边界由 Host 收紧。第三Server 之间互相不可见。每个 Server 只看到自己这条连接上的请求。跨 Server 的编排——比如从数据库读结构、改完代码再发 GitHub PR——由 Host 内的 LLM 或编排逻辑完成协议本身不提供 Server 间直连的能力。MCP 解决的是接入标准化不是编排标准化这两件事经常被混为一谈。三、三大核心原语Tools、Resources、PromptsServer 能向 Client 暴露三种核心原语Primitives。三者的技术形态相似但控制权归属完全不同这是理解 MCP 设计哲学的关键原语控制方读写属性典型用途类比Tools工具模型控制model-controlled可写、有副作用查数据库、发请求、写文件、触发构建编程语言里的函数调用Resources资源应用控制app-controlled只读暴露文件内容、日志、配置、数据记录REST 里的 GET 资源Prompts提示模板用户控制user-controlled只读模板预置的代码审查模板、分析任务模板应用里的斜杠命令Tools模型可主动调用的能力。Tool 是暴露给 LLM 的可执行函数带名称、描述与 JSON Schema 参数定义。模型在推理过程中根据上下文决定何时调用、传什么参数。因为允许副作用写数据库、发消息、删文件Tool 是三种原语里安全模型最重的一个——规范要求 Host 在执行前获得用户确认的机制。Resources应用读取的数据。Resource 以 URI 形式标识如file:///path/to/schema.json由应用决定加载哪些内容挂进上下文模型不主动调用资源。语义上就是只读数据源代码文件、日志片段、数据库记录。这个区分有实际意义——把静态数据塞进 Resource 而不是包装成 Tool可以避免模型在不需要时误触发读取。Prompts用户主动触发的模板。Prompt 是 Server 预定义的提示词模板带参数由用户显式选用通常呈现为斜杠命令或模板菜单再由应用展开后交给模型。它解决的是把成熟用法固化的问题一个代码审查 Server 可以预置 “review-diff” 模板用户一键触发不必每次手写审查提示词。除了这三种 Server 提供的原语MCP 还定义了反向能力Server 可以请求 Client 侧做事比如samplingServer 请 Host 的 LLM 补全一段文本与rootsClient 告知 Server 它被授权操作的目录边界。这部分用得较少知道有这层机制即可。四、通信机制JSON-RPC 2.0、传输层与完整生命周期4.1 消息格式JSON-RPC 2.0MCP 的消息层建立在 JSON-RPC 2.0 之上。这个选择很务实JSON-RPC 是一个极简的远程过程调用规范全部消息只有三种消息类型特征是否期待响应MCP 中的例子Request带method、params与唯一id是initialize、tools/list、tools/callResponse对应某个 Request 的id含result或error—initialize 的返回、工具执行结果Notification有method但无id否notifications/initialized、notifications/tools/list_changedRequest 与 Notification 的区别只在于有没有id有id的一定要回响应没有id的发出去就完事。JSON-RPC 2.0 同时规范了错误对象的结构code、message、data让所有 Server 的错误行为一致上层不用逐个适配。4.2 传输层stdio 与 Streamable HTTP传输层定义消息在物理上怎么跑。当前规范提供两种标准传输维度stdioStreamable HTTP适用场景本地进程Server 与 Host 同机远程部署Server 跨网络通信方式Server 作为子进程启动走标准输入/输出单一 HTTP 端点POST 请求 可选 SSE 流式响应部署形态Host 启动时拉起进程独立服务多客户端复用认证鉴权依赖本机进程权限标准 HTTP 认证OAuth 2.1 等典型例子本地文件系统 Server、本地数据库 CLI 封装云端 GitHub Server、企业内部工具网关有个历史包袱值得说明早期规范2024-11-05 版的远程传输是 HTTPSSE 双端点方案——客户端向一个端点 POST从另一个 SSE 端点接收推送。2025 年 3 月的规范修订用 Streamable HTTP 取代了它单一端点支持按需升级为流式响应显著简化了部署与基础设施兼容性。现在读到的旧教程里如果还在讲 HTTPSSE请注意那已经是被废弃的方案。4.3 生命周期从握手到断开一次完整的 MCP 会话分四个阶段Client Server │ │ │──── initialize 请求 ─────────│ ① 握手交换协议版本与能力 │─── initialize 响应 ─────────│ │──── initialized 通知 ────────│ ② 进入正常通信 │ │ │──── tools/list ──────────────│ ③ 常规操作发现、调用、订阅 │─── 工具清单 ─────────────────│ │──── tools/call ──────────────│ │─── 执行结果 ─────────────────│ │ │ │──── 断开进程退出 / 连接关闭│ ④ 结束会话阶段一initialize 握手。Client 发送initialize请求携带自己支持的协议版本与能力集合Server 响应自己支持的版本与能力。双方取交集后续会话只使用共同支持的部分。版本不一致时Server 应回退到自己支持的较早版本并在响应中声明Client 决定是否接受。这是典型的能力协商capability negotiation——协议演进不依赖全体同步升级。阶段二initialized 通知。握手完成后 Client 发出notifications/initialized通知会话正式进入可用状态。在此之前双方不应交换其他消息。阶段三正常通信。Client 调用tools/list、resources/list、prompts/list发现能力用tools/call等方法执行操作。能力动态变化时Server 可以发notifications/tools/list_changed之类的通知让 Client 重新拉取清单。阶段四断开。stdio 场景下进程退出即断开HTTP 场景下关闭连接。规范没有强制会话恢复机制重连意味着重新走一遍握手。五、代码实战一用 FastMCP 写一个最小可用的 MCP Server官方 Python SDK 的上层封装 FastMCP 把实现一个 Server 的成本压到了几十行以内。下面的例子实现一个数据库表结构查询Server可以直接运行# db_inspector_server.py# 依赖安装pip install fastmcpfromfastmcpimportFastMCP mcpFastMCP(db-inspector)# 模拟的数据字典真实场景中可连接 information_schema 查询TABLE_SCHEMAS{orders:CREATE TABLE orders (id BIGINT PRIMARY KEY, user_id BIGINT NOT NULL, amount DECIMAL(10,2), status TINYINT, created_at DATETIME);,users:CREATE TABLE users (id BIGINT PRIMARY KEY, name VARCHAR(64), email VARCHAR(128), created_at DATETIME);,}mcp.tool()defget_table_schema(table_name:str)-str:查询指定表的建表语句。table_name 为表名如 orders、users。schemaTABLE_SCHEMAS.get(table_name)ifschemaisNone:returnf表{table_name}不存在。可用表{, .join(TABLE_SCHEMAS)}returnschemamcp.tool()deflist_tables()-list[str]:列出数据库中所有可查询的表名。returnsorted(TABLE_SCHEMAS.keys())if__name____main__:mcp.run()# 默认使用 stdio 传输mcp.run(transporthttp) 可切换为远程模式几个值得注意的设计细节。装饰器即注册。mcp.tool()把普通函数注册为 MCP Tool函数名即工具名docstring 即工具描述。描述质量直接影响模型调用准确率——模型靠它判断什么时候该用这个工具写成查表不如写成查询指定表的建表语句输入表名。类型提示生成 Schema。参数类型注解table_name: str、返回list[str]会被自动转成 JSON Schema不需要手写。类型越精确Literal、Enum、dataclass模型传参越不容易出错。返回值即结果。返回的字符串会被包装成tools/call响应里的 content 内容回传给 Client。FastMCP 也支持返回 dict 与自定义对象框架负责序列化。写完之后把该 Server 挂进任意支持 MCP 的 Host在配置文件里声明启动命令python db_inspector_server.pyHost 启动时会以 stdio 方式拉起这个进程模型即可调用get_table_schema与list_tables。整个过程不需要改动 Host 的任何代码——这正是协议标准化的价值。六、代码实战二Client 与 Server 的 JSON-RPC 报文全过程上层框架把细节都藏掉了但排查问题、做性能分析、写自定义 Client 时必须看得懂线上的真实报文。下面是一次完整交互的 JSON 明文。第一步initialize 握手能力协商。Client 发出的请求{jsonrpc:2.0,id:1,method:initialize,params:{protocolVersion:2025-06-18,capabilities:{roots:{listChanged:true},sampling:{}},clientInfo:{name:my-mcp-client,version:1.2.0}}}Server 的响应{jsonrpc:2.0,id:1,result:{protocolVersion:2025-06-18,capabilities:{tools:{listChanged:true},resources:{subscribe:true,listChanged:true},prompts:{listChanged:true}},serverInfo:{name:db-inspector,version:1.0.0}}}注意capabilities字段的语义Client 声明自己支持roots与samplingServer 声明自己提供 tools、resources、prompts 三类能力。会话接下来的所有操作都被这份清单约束——Server 没声明resourcesClient 就不应该向它发resources/list。第二步initialized 通知无 id不期待响应。{jsonrpc:2.0,method:notifications/initialized}第三步发现工具。{jsonrpc:2.0,id:2,method:tools/list}响应里每个工具都带完整的 JSON Schema 描述模型上下文里消耗的 token 主要就来自这里——记住这一点后面讨论争议时会用到。第四步调用工具。{jsonrpc:2.0,id:3,method:tools/call,params:{name:get_table_schema,arguments:{table_name:orders}}}Server 的响应{jsonrpc:2.0,id:3,result:{content:[{type:text,text:CREATE TABLE orders (id BIGINT PRIMARY KEY, user_id BIGINT NOT NULL, amount DECIMAL(10,2), status TINYINT, created_at DATETIME);}],isError:false}}错误处理走两条路协议层错误方法不存在、参数不合法用 JSON-RPC 标准的error对象返回工具执行层面的业务失败则放在result.isError: true中content 里带可读的错误信息让模型有机会自行修正重试。这个区分很实用——前者说明你调错了接口后者说明工具本身执行出了问题。七、行业格局从一家开源到全行业跟进MCP 的行业采纳速度在开放协议里相当罕见几个关键节点如下。2024 年 11 月Anthropic 发布并开源 MCP同时提供 Python、TypeScript、Java、Kotlin、C# 等多语言 SDK其中部分 SDK 由微软、JetBrains 等公司贡献维护。Block、Apollo 等公司是最早的一批生产环境采用者。2025 年 3 月OpenAI 宣布其 Agents SDK 将支持 MCP。此前市场普遍预期 OpenAI 会推自己的工具调用标准这一转向意味着两大模型厂商在工具协议层面走向收敛。Sam Altman 本人在社交平台上的表态相当直接——开发者喜欢 MCPOpenAI 顺应这个方向。2025 年 4 月Google DeepMind 确认其 Agent Development KitADK将支持 MCP。至此三大头部模型厂商全部站在了同一协议侧MCP 事实上成为 Agent 工具连接的行业标准。生态侧LangChain/LangGraph 将 MCP 纳入工具接入体系Cloudflare 提供了构建远程 MCP Server 的基础设施方案Replit、Sourcegraph 等开发工具厂商陆续集成微软在 VS Code、Copilot Studio、Windows AI Foundry 等产品线中接入了 MCP 支持。多语言 SDK、参考 Server 实现与规范文档在开源仓库中持续演进截至 2026 年年中仍保持活跃迭代节奏。从工程视角看巨头跟进的真正意义不在谁赢谁输而在供给端统一之后生态分工清晰了工具方写一次 Server 可以服务所有 Host应用方接一次协议可以使用所有工具中间不再需要逐对定制。这与 HTTP 统一 Web、USB 统一外设接口的路径一致——标准本身不产生利润但降低了所有人的集成成本。八、争议与反思Token 成本与绕过 MCP的公开建议MCP 不是没有代价2026 年以来最值得工程师关注的一场公开争议来自微软 Playwright 团队。事件本身Playwright 官方维护的 playwright-mcp让 AI 通过 MCP 协议控制浏览器进行自动化测试的 Server在其 GitHub README 中公开建议——对于编码类 Agentcoding agent优先使用 CLI 工具加 Skills 机制而非 MCP。README 中给出的量化理由是CLI 方案的 token 消耗约为 MCP 方案的 1/4。这是第一个主流厂商在自己的官方仓库里公开建议绕过 MCP的案例社区反应相当激烈。成本从哪来两个结构性来源。其一工具 schema 常驻上下文。每个挂载的 MCP Server 在会话开始时都要通过tools/list把全部工具的 JSON Schema 注入模型上下文这部分 token 是底噪——不管本次任务用不用得上这些工具都要先付一遍钱。挂的 Server 越多、工具越多底噪越大。其二结构化结果的序列化开销。MCP 的返回是结构化 JSON浏览器自动化场景下是序列化的 DOM 快照信息密度低于等价的 CLI 纯文本输出。 playwright-mcp 场景下 DOM 快照尤其重同样的信息量结构化形式消耗的 token 数倍于命令行输出。如何理性看待Playwright 的建议针对的是特定场景——编码 Agent、高频原子操作点按钮、填表单、读 DOM。在这些场景里CLI 调用路径短、输出紧凑确实更划算。但把这条建议外推成MCP 已过时就过度了CLI 没有统一的服务发现与能力协商每接一个新工具仍要写胶水代码跨工具编排数据库 代码仓库 消息通知联动时 CLI 方案的工程成本会反超。Playwright 团队自己也只是建议编码场景优先 CLI并没有否定 MCP 在其他场景的价值。工程界的实际收敛方向是双轨制场景特征推荐路径理由高频原子操作文件读写、shell 命令、git 操作、浏览器单步控制CLI Skillstoken 开销低、延迟小、无 schema 底噪跨系统编排同时要数据库 GitHub Slack 等多个系统MCP统一接入与能力协商胶水代码趋零需要标准化对外提供能力工具要被多个 Host 复用MCP一次实现多方调用避免逐对适配Token 预算严格受限的会话CLI 或按需挂载 MCP Server控制上下文底噪企业内部工具网关、需要集中治理与审计MCP远程 Streamable HTTP 部署统一鉴权、审计、版本管理换句话说高频原子操作走 CLI/Skills跨工具编排走 MCP。两条路径解决的不是同一问题争论谁取代谁没有工程意义问题是你的场景落在哪一侧。九、实践建议什么时候用 MCP什么时候不必用落到自己的项目里给一组可以直接执行的判断。该用 MCP 的信号Agent 需要同时接入三个以上异构系统数据库、代码仓库、内部 API、消息平台逐对写胶水代码的维护成本已经失控你构建的工具能力需要被多个不同 Host 复用——写一次 ServerClaude Desktop、Cursor、自研 Agent 全都能用团队需要统一的工具治理层集中鉴权、审计日志、版本管理远程 MCP Server 部署在网关后工具集合会频繁变化需要动态发现与能力协商而不是每次改配置重发版不必硬上 MCP 的信号单工具高频调用尤其 token 敏感的会话——先算 schema 底噪的账一次性脚本、本地个人工作流CLI 一行命令能解决的事工具调用逻辑高度定制、与特定 Host 深度耦合标准化收益趋近于零落地 checklist检查项要点传输层选型本地工具用 stdio对外/跨网络服务用 Streamable HTTP并启用 OAuth 鉴权工具粒度单个工具职责单一、参数 Schema 精确用 Literal/Enum 收窄取值描述写清何时该用token 预算统计每个 Server 的 schema 底噪低频工具考虑懒加载或独立会话挂载避免常驻错误处理业务失败放isError: true让模型自愈协议错误走标准 error 对象日志里区分两者安全边界写操作工具在 Host 侧强制用户确认Server 只暴露最小能力集不透传敏感凭据版本管理initialize 时校验 protocolVersionServer 端做好向后兼容能力变更发 list_changed 通知降级预案关键链路准备 CLI 等价路径MCP Server 不可用时业务不中断最后一条值得多说一句把 MCP 当作接入标准而非信仰。协议解决的是接得上、接得统一不承诺用得省、用得快。token 成本、延迟、稳定性这些运行时指标仍要在自己的场景里实测拿数。十、总结回顾全文的主线。架构层MCP 用 Host-Client-Server 三方拓扑与一对一连接设计换来了状态隔离与安全边界清晰接入标准化MCP 管与编排智能化Host 内 LLM 管是两件不同的事不要混为一谈。协议层三大原语按控制权划分——Tools 归模型、Resources 归应用、Prompts 归用户比全部塞成工具调用的朴素做法在语义与安全上都更精细。JSON-RPC 2.0 加 stdio/Streamable HTTP 双传输本地与远程部署都有标准路径initialize 握手的能力协商让协议可以平滑演进。实战层FastMCP 十几行代码能跑起一个可用的 Server但生产化的重点在 schema 质量、错误语义、token 底噪控制与安全边界——这些细节决定了工具被模型调用时的准确率与成本。行业层OpenAI 与 Google DeepMind 先后跟进MCP 已是事实标准Playwright 团队公开建议编码 Agent 用 CLI 替代 MCP把 token 成本这个真实短板摆上了台面。工程上的收敛答案是双轨高频原子操作走 CLI/Skills跨工具编排走 MCP。留给两个技术讨论你的项目里MCP Server 的工具 schema 大约占掉多少会话 token有没有做过量化对比编码 Agent 场景你实测下来 CLI 与 MCP 的 token 消耗差距有多大哪些操作你留给了 MCP哪些退回了 CLI评论区聊聊你的数据比争论MCP 好不好更有价值。