MCP 2026-07-28 协议边界：Client、Server、Tools、Resources 与 Streamable HTTP

本文定位：MCP 2026-07-28 协议分层与边界

这篇文章只负责回答 MCP 的协议边界：Client、Server、Tools、Resources、Prompts、stdio、Streamable HTTP、MRTR 和 Tasks extension 分别承担什么职责，以及 2026-07-28 为什么移除协议级 Session。具体代码实战请看 MCP Server SQLite 私有数据挂载；公网部署请看 MCP Streamable HTTP 实战；认证与授权请看 MCP OAuth 认证实战。

直接答案：MCP 2026-07-28 的最大变化不是新增一个 API，而是把核心协议改成 stateless request/response。 initialize / notifications/initialized 和协议级 Mcp-Session-Id 已退出核心流程；每个请求自己携带协议版本、Client 能力与身份元数据。Server 必须实现 server/discover，但 Client 不必每次先调用；远程部署主线是 Streamable HTTP，legacy HTTP+SSE、Roots、Sampling、Logging 已进入弃用窗口。

协议边界复核清单

读完这篇后，至少要能区分：

• Client 负责发起自描述协议请求、声明自身能力，并处理需要用户/模型输入的 MRTR，不应该替 Server 承担业务授权。
• Server 负责暴露资源和工具清单，必须做权限、超时和日志治理。
• Resources 偏只读上下文，Tools 可能产生副作用，安全等级不同。
• stdio 适合本地进程边界；远程团队共享应走 Streamable HTTP 与独立认证/授权层。
• 协议 stateless 不等于业务 stateless；审批、长任务、购物篮、上传等状态应使用显式业务 ID/handle 存储。
• MCP 不是万能插件市场，真正价值在标准化、可审计和可治理。

先给结论：MCP 是 AI 调用本地工具的协议边界

MCP 的价值不是“让模型随便操作本机”，而是把本地工具、文件、数据库和远程服务封装成可发现、可限权、可审计的能力清单。它适合私有数据库挂载、企业内部工具链集成和自动化代码重构，但必须提前设计权限、日志、超时和隔离边界。

• 适合场景：本地私有数据库挂载、企业级内部工具链集成、自动化代码重构工作流。

本文解决的问题：按 2026-07-28 重新锁定协议边界

• MCP 2026-07-28 为什么改成 stateless？
• server/discover、Mcp-Method、Mcp-Name 分别承担什么职责？
• stdio、Streamable HTTP 与 legacy HTTP+SSE 怎么选？
• MRTR 如何替代过去的 server-initiated request 思路？
• Tasks extension 与普通同步 Tool Call 的边界是什么？
• Roots、Sampling、Logging 被 deprecated 后应该迁移到哪里？

适合谁阅读

• AI 应用开发者：想为自己的应用增加强大的本地扩展能力。
• 全栈工程师：想掌握 2026 年最主流的 AI 插件开发标准。
• 系统架构师：正在设计企业级 AI 智能体平台的底层连接协议。

一、 Xiaobai’s Note

贵阳这两天的清晨总有一层薄薄的雾气。我坐在“本地开发环境”工作室，看着屏幕上正通过 MCP (Model Context Protocol) 协议与我的本地数据库疯狂对话的 Cursor，不禁感叹：2026 年，如果你还不懂 MCP，那你跟 AI 协作的效率可能还停留在石器时代。如果说 Agent 是我构建的“指挥中心”，那么 MCP 就是这套系统的“USB-C 接口”。它不仅统一了 AI 与外部世界的通信协议，更彻底打破了“本地数据孤岛”。今天，我就以实战视角，带你拆解这个正在改变 AI 生态的底层协议。

一、 MCP 是 AI 时代打破数据孤岛的底层物理标准

以前，AI 是一个关在玻璃房里的天才，你想让它看一眼你本地的财务表格，你得手动复制粘贴，或者写一个极其脆弱的特定插件。现在，有了 MCP，你只需要给玻璃房装上一个标准化的“抽屉”。AI 需要什么，直接通过抽屉（协议请求）向你索取，你把数据放进去（协议响应）即可。

MCP 为 Host/Client 与外部能力 Server 之间提供统一的 JSON-RPC 协议。到 2026-07-28，能力发现和请求路由不再依赖持久 Session：请求自己携带协议版本、Client 信息和能力元数据，需要预先探测时再调用 server/discover。

二、 MCP Client、Server Tools

1. MCP Client (大脑容器)：协议的发起方，如 Cursor、Claude Desktop。它负责维护上下文，并决定何时触发调用。
2. MCP Server (协议中继器)：开发者编写的轻量级进程，负责封装真实的逻辑并暴露能力清单。
3. Tools & Resources (底层手脚)：实打实的代码逻辑，包括可执行的 Tools（如查询数据库）和可读取的 Resources（如读取文件流）。

三、对比：stdio、Streamable HTTP 与 legacy HTTP+SSE

维度	stdio	Streamable HTTP	legacy HTTP+SSE
主要场景	本地子进程工具	当前远程 MCP 主线	旧客户端兼容
协议状态	进程连接存在，但 2026 请求语义仍自描述	stateless request/response，可按请求落到不同实例	旧式长连接/双端点思路
伸缩	由 Host 管理本地进程	适合普通负载均衡与多副本	更容易受 sticky/长连接约束
安全重点	OS 用户、文件权限、stderr	HTTPS、OAuth、Origin/Host、Tool authorization	仅为兼容维护，不建议新建
2026-07-28 状态	当前支持	当前推荐	Deprecated

不要把“Streamable HTTP”理解成“换了一个 SSE URL”。2026-07-28 同时移除了核心 handshake、协议 Session、SSE resumability/message redelivery。响应流断开时，Client 应把未完成请求作为新请求重新发出，并使用新的 request id；业务上的幂等和去重仍由应用负责。

四、MRTR 与 Tasks：为什么 stateless 仍然能处理多轮和长任务

过去 MCP 的 server-to-client sampling、elicitation、roots 等能力依赖 Server 主动向 Client 发请求。2026-07-28 引入 Multi Round-Trip Requests（MRTR）：Server 可以先返回 resultType: "input_required" 和 inputRequests，Client 收集所需输入后重试原业务请求，并通过 inputResponses 带回结果。这样不需要长期保持一个双向协议 Session。

长任务则进入 io.modelcontextprotocol/tasks 扩展。它使用任务 handle、tasks/get 轮询以及 tasks/update 继续输入，和普通同步 Tool Call 分层。协议层提供任务生命周期，不替你解决支付、部署、发信等外部副作用的幂等。

五、Roots、Sampling、Logging 进入弃用期，别把“仍可用”写成“新项目应该用”

2026-07-28 已把 Roots、Sampling、Logging 标记为 deprecated，至少保留十二个月迁移窗口。新实现应按官方建议迁移：文件/目录范围通过 Tool 参数、Resource URI 或 Server 配置表达；模型调用直接接 Provider API；日志走 stderr（stdio）或 OpenTelemetry。

这里尤其要区分 MCP Roots 和你自己 Server 的 allowedRoots：前者只是 Client 提示相关目录，且不是访问控制机制；后者如果由 Server 强制执行 realpath、身份和操作权限校验，仍然可以是有效的应用安全边界。

实战避坑与报错指南 (Error Logs)

1. Error: Stdio Stream Pollution
   • 原因：你的代码中包含了 print() 或 console.log()，这些杂质破坏了 Stdio 上的 JSON-RPC 通信。
   • 对策：所有的调试日志必须通过 stderr (Python 的 sys.stderr 或 TS 的 console.error) 输出。
2. Error: Zombie Process Detected
   • 原因：Client 异常退出后，MCP Server 进程没有被正确销毁。
   • 对策：监听 SIGTERM 信号，并增加“看门狗”逻辑，如果 5 分钟无心跳则执行 process.exit(0)。
3. Error: JSON-RPC Buffer Overflow
   • 原因：尝试通过 Resource 返回几十 MB 的大文件，塞爆了 Stdio 缓冲区。
   • 对策：永远不要通过 MCP 返回大文件。应先进行摘要提取或分块检索（RAG）。

七、 常见问题解答

Q: 为什么我的 Cursor 识别不到新加的 Tool？

A: 点击 Cursor MCP 配置界面的 Refresh。如果依然失效，检查你的函数是否有正确的 Docstring（文档注释），AI 极度依赖注释来理解工具意图。

Q: 如何解决 MCP 连接远程服务器的安全问题？

A: Tunnel 只能解决网络入口，不等于授权。远程 MCP 应使用 Streamable HTTP + HTTPS，并按当前 Authorization 规范处理 Protected Resource Metadata、Resource Indicator、Issuer 校验和 Tool 级授权；详见 MCP OAuth 认证实战。

推荐深度阅读

• 👉 MCP Server 实战：让 Claude 访问本地 SQLite 的 5 个步骤与避坑指南
• 👉 AI Agent 架构：构建自主智能体系统的 5 个核心模块
• 👉 LangGraph 实战：构建不跑偏 AI Agent 工作流的 3 个设计模式

我最近在持续研究：

• MCP 协议在大规模分布式 Agent 集群中的性能表现
• 基于 MCP 的跨 IDE (Cursor/Zed/VSCode) 统一工作流标准
• Streamable HTTP 下基于 Mcp-Method / Mcp-Name Header 的网关路由与授权

如果你在构建 MCP Server 时遇到诡异的协议报错，欢迎留言与我讨论。

• MCP 实战指南：从入门到进阶

• MCP vs Function Calling：为什么它是 AI 时代的 USB 接口？

• MCP Server 实战：让 Claude 访问本地 SQLite

• LangGraph 实战指南：构建有状态智能体

• AI Agent 实战手册

• 「问」MCP Tool Timeout 怎么处理？ A: 先区分网络/代理读取超时、单次 Tool 执行超时和 Tasks 长任务；不要把“调大 timeout”当成统一修复。长任务优先考虑显式 Task handle、幂等和恢复策略。

• 「问」如何保证本地数据库安全？ A: 使用只读账号，并结合环境变量限制物理路径访问。

专题入口 / MCP Hub

继续按 MCP 生产部署路径读，而不是堆 guide / tutorial

MCP 内容统一按协议理解、本地 Server、远程部署、OAuth、安全治理、stdio/JSON-RPC 排障和工具对比来承接，避免站内关键词互相抢。

进入 MCP 专题 → 查看安全治理清单 订阅