MCP协议与规范

1. 场景概述

在企业已经部署了自建 MCP Server（例如内部知识库检索、工单系统工具）或计划接入第三方 MCP Server（例如 GitHub MCP、Notion MCP）场景下，可以通过智能体广场统一接入这些 MCP Server，而不是让每个 Agent 分别直连后端端点。

智能体广场MCP服务，不改变后端 MCP 协议行为，并在入口层提供以下能力：

• **统一入站认证：**为 MCP 服务增加统一的访问控制，避免后端端点裸暴露。
• **统一工具发现：**通过 MCP 工具集（Toolset）集中管理工具入口，降低多 Agent 场景的配置成本。

2. 核心概念

2.1 Streamable HTTP

Streamable HTTP 是 MCP 的一种传输方式，基于 HTTP 请求承载 JSON-RPC（JSON Remote Procedure Call）消息，支持以流式方式返回结果。

在本文中，后端 MCP Server 需要提供可被智能体广场服务网关调用的 Streamable HTTP 端点，例如https://your-mcp-server.internal:8080/mcp/v1（路径可自定义）。

2.2 tools/list 与 tools/call

• tools/list：用于枚举后端 MCP Server 提供的工具列表，返回result.tools数组。
• tools/call：用于调用某个工具，通常包含工具名与入参（例如 {"query": "xxx"}）。

3. 工具描述与入参 Schema 编写规范

要求	反例 → 正例
以祈使句描述可执行动作	❌「可以先查一下文件」 → ✅「调用 search_files 查询」
description 须包含用途、适用场景与触发关键词	❌「搜索文件」 → ✅「按关键词搜索云端盘文件。适用于网盘文件检索场景」
inputSchema 须完整	❌ 所有字段均为可选且无说明 → ✅ 标注类型、必填、枚举与默认值，并为每个字段提供说明
参数化取值	❌ 固定写入folder_id → ✅ 由调用方传入 {folder_id}
单一工具单一职责	❌「搜索文件、修改权限并发送邮件」 → ✅ 拆分为三个工具
返回结构稳定	❌ 返回值类型在数组与字符串之间变化 → ✅ 固定字段名与结构，供调用方依赖
错误语义可判定	须区分不可重试错误（参数错误、权限不足）与可退避重试错误（限流、上游超时），并在错误对象中提供稳定的code
清单规模控制	工具数量过多将增加装配侧的注入体积；分档阈值参见主文档《工具选取方案》，超出阈值的能力须支持两级或三级漏斗筛选

4. 协议版本兼容

4.1 MCP 支持的协议版本

不同协议版本在交互方式上可能存在差异。例如，MCP 2026-07-28相比旧版协议，演进为更适合网关和 Serverless 场景的“无状态调用模型”，因此在初始化、会话保持、多轮交互方式上与旧版不同。MCP 协议版本用于定义消息格式、能力声明、初始化方式和调用行为；Streamable HTTP 是消息传输方式，二者是不同概念。当前通过 Streamable HTTP 对外提供访问时，客户端仍需根据自身支持情况选择对应的 MCP 协议版本进行调用。

MCP 服务	MCP 工具集
-2026-07-28 - 2025-11-25 - 2025-06-18 - 2025-03-26	-2026-07-28 - 2025-11-25 - 2025-06-18 - 2025-03-26

4.2 MCP 2026-07-28 协议兼容性说明

MCP 现已完成 MCP 2026-07-28 协议兼容性改造，改造后您仍可使用旧版协议调用 MCP 服务/MCP 工具集。

对于已有的 MCP 服务和 MCP 工具集，可采用以下低改造成本的兼容方案：无需修改存量 MCP 服务，只需将存量 MCP 服务添加至 MCP 工具集，即可通过 MCP 工具集使用新协议能力。

4.3 MCP 工具集新协议兼容规则

存量 MCP 工具集兼容逻辑

• 存量无影响规则：使用 MCP 2026-07-28 无状态协议调用 MCP 工具集时，可以访问工具集内已有的工具，无需关注各工具实际使用的协议。原有调用方式仍可继续使用。
• 下游工具兼容能力：MCP 工具集支持添加采用有状态或无状态调用方式的下游工具。调用 MCP 工具集时，客户端无需感知下游工具实际使用的协议或会话机制。
• 客户端改造要求：客户端可以使用有状态或无状态调用方式访问 MCP 工具集。切换至 MCP 2026-07-28 协议时，只需按照该协议调整客户端的调用逻辑，无需修改 MCP 工具集内已有工具所使用的协议。
• MRTR 工具调用要求：如果需要调用支持 MRTR（Multi Round-Trip Requests，多轮往返请求）的工具，客户端必须使用 MCP 2026-07-28 协议向 MCP 工具集发起请求。

5. 安全与鉴权方案

以下要求适用于接入智能体广场的三方 MCP Server。

5.1 传输与端点

要求	具体标准
强制 HTTPS	TLS 1.2 及以上（建议 1.3），证书由公共 CA 签发且在有效期内；不接受明文 HTTP
仅 remote 形态	必须提供 Streamable HTTP 端点；不支持 stdio、本地进程或随包分发形态
无内网依赖	端点不得指向内网地址、回环地址，也不得依赖内部 DNS

5.2 鉴权

类型	适用场景	必须满足
无鉴权	公网开放数据	声明为「无鉴权」，由平台在入口层兜底限流
静态凭据	API Key / Basic / PAT / 静态 Bearer	凭据由平台托管与轮换，服务侧不得落盘
用户 OAuth	访问用户自有数据	授权码流 + PKCE；发布受保护资源元数据；令牌 audience 绑定；禁止令牌透传

OAuth 类必须实现的标准：

要求	对应标准
发布受保护资源元数据（.well-known/oauth-protected-resource）	RFC 9728（MCP 规范强制）
支持授权服务器元数据发现	RFC 8414 或 OIDC Discovery（MCP 规范强制）
使用授权码流 + PKCE	RFC 7636、RFC 9700（OAuth 2.0 安全最佳实践）
令牌 audience 绑定，按资源请求令牌	RFC 8707
声明 scope 且最小必要	RFC 6749 §3.3
401 返回WWW-Authenticate；scope 不足返回 403	RFC 6750
禁止令牌透传：不得把收到的用户令牌原样转发给上游	MCP 规范安全要求

鉴权红线：

1. 一个 server 只允许一种鉴权方式，不拆分到工具级；同一 server 混装「公开数据工具」与「用户数据工具」必须拆成两个 server。
2. 授权懒触发：用户首次实际调用时才授权，装配阶段不预授权。
3. 授权失效（过期或撤销）后调用必须返回 401 / 403，由平台提示重新授权。

5.3 凭据与密钥管理

要求	说明
禁止硬编码	server 内不得出现 AK/SK、令牌、密码、PRIVATE KEY、数据库连接串、内网地址
不得接收用户凭据	后端只接受网关注入的凭据，不接收、不存储调用方的用户令牌
支持轮换	静态凭据可经平台控制台更新；OAuth refresh token 须支持轮换
日志脱敏	日志与错误响应不得包含令牌、Authorization 头或凭据原文

5.4 数据安全与多租户隔离

要求	说明
数据最小化	仅返回完成本次工具调用所必需的数据
租户隔离	缓存与索引必须以 tenant + user 为键；禁止跨用户、跨租户读取或聚合
越权防护	声明 scope 之外的数据一律不得返回；入参中的资源标识须做归属校验（防越权访问对象）
敏感信息	个人信息按最小必要处理；涉及数据出境须完成合规评估

附录 A：规范依据与协议对照

Model Context Protocol 规范 2026-07-28（无状态版本），https://modelcontextprotocol.io/specification/2026-07-28