Appearance
MCP 如何发现能力：Self-describing Request、Discovery 与 Tools
前置：MCP 的执行边界：Host、Client、Server 与 Stateless Core
核心问题：MCP 返回一组可发现能力后，Harness 怎样把它们安全地变成内部 ToolSpec，而不是直接信任远端 schema？
负载均衡把两次请求路由不同实例仍能独立解析，而任务进度保存在 host/task store。先 tools/list 获取工具元数据，Host 再按 tenant/risk 过滤后放入自己的 Tool Registry。
Self-describing Requests
请求应携带处理所需的协议/能力上下文，减少连接前置 handshake 的隐式依赖。自描述不等于把应用全部状态放请求，而是避免 transport session 成为协议事实。
Discovery
Discovery 用来按需了解 server 的能力与可用表面。它与 Tool Search 不完全相同：协议 discovery 是 server-level capability 描述，具体 tool catalog 仍需要 list/cache/filter 等机制。
发现到能力不等于自动授权执行。
🔍 源码对照：MCP Discovery 如何投影到 Harness Tool Registry
完整源码与通用分析见 06-03 Tool Metadata / Dynamic Discovery。这里不重复代码；这里关注 MCP discovery：自描述协议提供 capability metadata，但“发现了 Tool”不等于“已经授权”，也不等于 Runtime 已接受该 contract。
源码说明
这个文件是 Discovery 的直接小案例：tools/list 从内部 listTools() 得到 rows，建立 name→Tool map，再对外投影 name/description/inputSchema/annotations；tools/call 只允许调用已经进入 map 的工具。它说明 discovery result 本身是 capability snapshot，而不是“任何字符串名称都可以发给后端试一下”。
工程边界
bridge 代码声明的是较旧 protocol revision，不能用于替换本模块维护的 MCP 2026-07-28 规范知识；这里只看 adapter/data-flow。
Shadow Harness 对照
- Remote catalog 带 revision/TTL/source identity；调用绑定到已发现的 Tool identity。
- List result 与实际 execution capability 之间要处理 stale/revoked 情况。
验证
先 list，再撤销远端 Tool，再 call；Adapter 必须将 stale capability 作为明确错误处理，而不是无限缓存旧 catalog。
Tools
MCP Tool 是 Server 暴露的可调用能力，带 name 、description、完整 JSON Schema 2020-12 input/output contract 等。Host/Client 仍需决定哪些 Tool 暴露给模型、如何授权、如何处理 tools/call 错误与 structured content；协议可调用不等于当前用户有权限执行。
Host 仍要做本地 policy、审批、错误规范化和 trace。
Discovery 怎样进入 Harness 的 Tool Registry
远程 MCP Server 暴露能力后，Host/Client 不应该把远程描述直接当成本地可执行函数。更稳的流程是：
text
MCP discovery
↓
remote capability descriptors
↓ validate / normalize / policy filter
Internal ToolRegistry
↓
Context Manager 选择本轮真正暴露的 tools
↓
Model例如远端同时提供 search_docs、delete_document、export_workspace。Discovery 只说明“服务器声称有这些能力”；本地 Harness 仍要根据 tenant、workspace trust、用户权限和当前任务决定后两个工具是否进入 catalog。
这也是 self-describing 的边界：descriptor 能减少 Host 对某个 Server 的硬编码，但不能替代本地 trust / authorization / schema validation。Server 描述是输入，不是安全事实。
Failure Modes
路由仍依赖解析 Body 而忽略自描述 Header
症状： Gateway 必须完整解析 JSON-RPC body 才知道 method/name。
为什么危险： 失去 2026 header routing 对代理、策略和可观测性的价值。
处理： 传播/验证 Mcp-Method 与需要的 Mcp-Name，并保持 header/body 一致。
如何验证
| Case | 断言 |
|---|---|
| 路由仍依赖解析 Body 而忽略自描述 Header | 构造 header/body 不一致请求，gateway/server 按策略拒绝或记录 conformance error。 |
关联源码
自测
- Client 第一次连接一个陌生 MCP Server 时，怎样发现它有哪些 Tool，而不是把能力列表写死在代码里？
- Discovery 返回的 schema 能描述能力，但为什么 Harness 仍需自己的 policy/capability filter？