核心 GUIDE
MCP Boundaries
MCP 把 Model 与 External Capability 连接起来，但 Protocol Boundary 不等于 Permission Boundary。Client 与 Runtime 仍然需要显式 Trust、Capability 与 Side-effect Control。
核心心智模型
MCP Boundary 定义 Client 与 Server 之间会跨越哪些 Capability Metadata、Input、Output 与 Lifecycle。Security 与 Reliability 来自应用如何 Scope、Validate 与 Authorize Capability，而不是 Protocol 本身自动提供。
为什么重要
团队采用 MCP 后，Capability Discovery 变得更容易，也可能无意中扩大 Reachable Action Surface。清晰 Boundary 会把 Interoperability 与 Authority 分开：Server 暴露 Tool 不代表每个 Agent/User 都能调用；Response 合法也不代表 Side Effect 合适。
01
把 Protocol Discovery 与 Runtime Authorization 分成两步
先 Inventory MCP Server 暴露的 Capability，再通过 Application Policy 过滤后才提供给 Model。验证 Input/Output Schema，把 User 与 Task Context 纳入 Authorization Decision，并对高后果 Operation 添加 Approval 或 Irreversible-action Gate。记录 Negotiated Capability，便于 Incident Review 重建当时哪些能力可达。
02
示例：CRM Server 同时暴露 Read 与 Export Tool
MCP CRM Server 同时提供 read_customer 与 export_all_customers。Support Agent 只需要 Scoped Read，因此 Client 只暴露读取能力，并隐藏 Export。Protocol 仍然 Interoperable，而 Runtime 保持 Least Privilege；如需额外 Capability，只能通过显式 Approval Path 获取。
常见失败模式
- 认为所有 Discovered MCP Capability 都应该暴露给 Model。
- 把 Schema Validity 当成 Action 已被 Authorized 的证明。
- 因为采用 MCP 就绕过原有 Approval 或 Audit Boundary。
工程启发
- 把 Capability Discovery 与 Capability Authorization 分开。
- 在暴露给 Model 前，按 Current Task 与 User Scope Tool。
- 高后果 Action 继续放在 Runtime Policy、Approval 与 Audit 之后。
关键结论
- 01MCP 标准化的是 Capability Exchange，不是 Trust。
- 02Protocol Reachability 不等于 Permission。
- 03Least Privilege 仍然属于 Application Runtime。
阅读记录
这里只记录你真实做过的动作，不代表掌握、熟练或认证。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。