核心 GUIDE
MCP Capability Negotiation
Capability Negotiation 让 MCP Client 只启用双方都支持、且当前 Task 被允许使用的 Feature 与 Operation，而不是默认所有 Available Capability 都处于 Active 状态。
核心心智模型
Negotiation 是 Compatibility 与 Policy Handshake：先 Discover 有什么，再与 Client Support 和 Application Authorization 求交集，最终建立当前 Session 或 Task 的 Effective Capability Set。
为什么重要
External Capability Surface 会持续演化：Server 增加 Tool，Protocol Feature 变化，不同 Client 支持的 Subset 也不同。如果 Application 假设 Capability Universe 永远固定，升级可能造成 Silent Failure 或意外 Overexposure。Negotiation 让 Capability Drift 可观察，也让 Runtime 有机会 Fail Closed。
01
显式推导 Effective Capability Set
在 Connection 或 Task 开始时读取 Server Advertised Capability，与 Client 支持的 Protocol Feature 以及 Application Allowlist 比较，再生成 Effective Set。Required Capability 缺失时必须显式处理；新出现的 Sensitive Capability 也不能自动启用。把 Negotiated Version 与 Capability Set 写入 Trace，以支持 Reproducibility。
02
示例：Server Upgrade 新增高权限 Write Capability
MCP Server Upgrade 后出现新的 delete_project Tool。Naive Client 因为 Discovery 成功就立刻暴露它。Negotiated Client 会把 Server Capability 与 Application Allowlist 求交集，因此新 Tool 在 Policy 与 Approval Flow 被显式更新前保持不可用。
常见失败模式
- 把 Server Advertised Capability 等同于 Effective Allowed Capability。
- Required Capability 或 Protocol Feature 缺失时 Fail Open。
- Trace 与 Incident Diagnosis 中不记录 Negotiated Capability Version。
工程启发
- 显式计算 Server、Client 与 Policy Capability 的交集。
- Required Capability 缺失或出现新 Sensitive Operation 时 Fail Closed。
- 记录 Negotiated Set，以便 Upgrade 后重现当时行为。
关键结论
- 01Negotiation 让 Capability Drift 显式化。
- 02Available 不等于 Supported，Supported 也不等于 Authorized。
- 03可复现 Session 应记录它的 Effective Capability Set。
阅读记录
这里只记录你真实做过的动作，不代表掌握、熟练或认证。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。