第 24 章详细 Outline：MCP 与外部工具集成

章节目标与核心问题

目标： 让读者把 MCP 接入理解为可审查的外部能力边界，而不是“添加一个工具”的快捷方式。
核心问题： 如何把工具发现、来源信任、任务范围、批准、调用结果和外部效果拆成不同证据？
前置章节： 第 11 章 Tool Use、第 12 章 Environment、第 14 章 Human-in-the-loop、第 15 章 Observation、第 17 章 Evaluation。
后续章节： 第 25 章浏览器路径验证、第 26 章多 Agent 任务隔离、第 27 章 Git 与代码审查。

节	读者问题	本节交付	事实与模型边界
场景引入	为什么“工具可见”不等于“任务可执行”？	一个文档更新与外部知识库同步的反例。	场景为教学设计，不是已运行集成。
协议不是授权	MCP Tools 提供了什么？	能力描述、列表、调用、结果与 annotations 的分层。	仅限 CH24-REF-01 的协议陈述。
Server Profile	怎样描述候选外部能力？	来源、所有者、传输、范围、刷新和未知项。	Profile 是本书模型。
Tool Admission Record	哪些条件必须在调用前满足？	任务范围、效果类别、环境、批准和观察计划。	准入记录不是 token、配置或调用。
Invocation Envelope	怎样避免“请求”被记成“完成”？	关联标识、输入摘要、效果类别、批准引用。	Envelope 不代表已发送。
Result Observation	结果和业务效果如何分离？	结果、错误、来源、新鲜度与独立验证。	返回值不是外部效果证明。
最小示例	如何拒绝不完整接入？	纯内存准入函数、八条测试路径。	不连接真实 MCP 或网络。
工程实践	如何把接入变成可维护系统？	小范围启用、最小 scope、日志、回滚与复核。	依据安全资料的风险背景扩展为本书规则。
错误与边界	常见混淆在哪里？	配置即信任、schema 即安全、工具成功即业务成功。	不宣称通用防护或合规。

计划图示： 候选 Server → Profile → Admission → Invocation → Result Observation → 独立验证；任一边界不完整时进入补证、人工审核或阻塞。
计划案例： 书稿助手希望通过外部 MCP 工具更新参考资料索引。它必须先声明目标库、写入效果、批准和回读验证，而不是因工具已被发现就执行。
计划示例： assessMcpIntegrationAdmission 只判定输入是否具备接入前的证据和停止条件。