一、这个技术是什么？

一个工具如果描述不清楚、参数不校验、权限过大，模型就可能误用工具，甚至执行危险操作。

MCP Server 设计的重点不是“暴露越多工具越好”，而是把能力拆成清晰、可验证、可审计的接口。

二、没有它之前发生了什么？

把一大段业务能力暴露给模型
↓
工具含义模糊，参数和副作用不清楚
↓
模型容易误选工具，系统难以审计
↓
工具边界、Schema、权限和确认机制被显式设计

三、核心概念

1. Tool Boundary

一个工具最好表达一个清晰动作，避免一个工具同时读取、修改和删除大量资源。

2. Input Schema

输入 Schema 需要描述字段类型、必填项、范围和业务约束。

3. Side Effect

读取通常风险较低，写入、删除、发送消息和执行命令属于需要谨慎处理的副作用。

4. Permission

Server 应遵循最小权限原则，只允许工具访问完成任务所需的数据和操作。

5. Audit

工具调用应记录调用者、参数摘要、结果、耗时和失败原因，便于追踪问题。

四、运行流程

五、面试复习

一句话回答

可靠的 MCP Server 需要清晰的工具边界、严格的输入 Schema、最小权限、可控副作用和审计日志，不能把安全责任交给模型。

高频追问

• 为什么工具不应该设计得过大？
• 如何处理模型传入的危险路径？
• 哪些操作必须人工确认？
• 工具返回值为什么要结构化？

容易答错

不要认为“模型调用工具”就等于“模型拥有系统权限”。真正执行操作的仍然是 Server，需要由代码实施权限和确认边界。

六、项目展示

知识库助手可以提供 search_notes、read_note 和 suggest_update 三类工具。其中读取工具可以自动执行，修改建议只生成 PR，不直接覆盖原始笔记。