一个 Agent 能做多少事，取决于它能调用多少工具。模型本身只会生成文本，真正把意图变成动作的，是它背后挂载的工具。MCP（Model Context Protocol）就是给 Agent 提供工具的一种标准方式，而 Deskmate 把这套机制做成了按 Agent 可控的开关。
MCP 是什么
MCP 是一个开放协议，用来描述「外部能力」如何暴露给模型。一个 MCP server 声明自己提供哪些工具、每个工具接受什么参数、返回什么结果；Agent 端通过统一的协议去发现和调用这些工具，而不必为每个集成单独写胶水代码。
可以把它理解成 Agent 世界的「USB 接口」：server 是设备，协议是接口标准。只要一个能力实现成了 MCP server，任意支持 MCP 的客户端都能接上它，无需关心它内部用什么语言、连了什么后端。
MCP server 如何成为 Agent 工具
当一个 MCP server 被挂载后，它声明的工具会进入 Agent 的可用工具列表。模型在推理时看到这些工具的名称和参数描述，决定是否调用、用什么参数调用；调用结果再回流给模型，参与下一步推理。
这意味着扩展一个 Agent 的能力，往往不需要改模型，也不需要改 Agent 的核心逻辑——挂上一个新的 server，工具列表就多了一组条目。能力的边界从「模型会不会」变成了「你给它接了什么」。
Deskmate 如何按 Agent 启用 server
Deskmate 不会把所有 server 一股脑塞给每个 Agent。工具越多，模型越容易选错，上下文也越臃肿。所以启用是按 Agent 粒度控制的：你为某个 Agent 显式声明它能用哪些 MCP server，未声明的就不可见。
这样做有两个好处：一是每个 Agent 的工具列表保持精简、贴合职责；二是权限边界清晰——一个只负责整理笔记的 Agent，没必要也不应该拿到操作数据库的工具。你可以用命令行查看当前的挂载状态：
app mcp status --json输出会列出已配置的 server、连接状态，以及它们暴露的工具，方便你确认某个 Agent 实际拿到了什么。
常见 server 类型
MCP server 的形态很多，常见的几类大致如下：
| 类型 | 典型能力 | 适合的 Agent |
|---|---|---|
| 文件 / 知识 | 读取目录、检索文档片段 | 写作、研究、答疑 |
| 数据库 / 数据 | 查询、聚合、只读分析 | 报表、运营分析 |
| 开发工具 | 代码搜索、构建、运行测试 | 编码、排障 |
| 网络 / 抓取 | 搜索、抓取网页内容 | 调研、信息收集 |
| 业务集成 | 对接内部 API 或第三方服务 | 流程自动化 |
这只是常见分类，并非内置清单——具体能接哪些，取决于你的环境里部署了哪些 server。
权限和安全建议
工具能做事，也就意味着能造成后果。引入 MCP server 时，建议遵循几条朴素的原则：
最小权限：只给 Agent 它职责范围内需要的 server，不要图省事全部打开。
优先只读：在熟悉一个 server 的行为之前，尽量从只读能力开始，确认无误再放开写操作。
- 谨慎对待会写文件、改数据或对外发请求的 server，它们的每次调用都是真实动作。
- 只接入你信任、来源清楚的 server；不清楚一个工具会做什么时，先别挂上去。
- 关注会向外部发送数据的工具，明确哪些信息会离开本地。
Deskmate 仍处在 early access 阶段，MCP 相关的配置和行为可能随版本调整。请把上面的建议当成默认姿态，而不是一次性设置完就不再过问。
第一个 MCP server 的试用流程
如果你是第一次接 server，可以按下面的顺序走一遍，先跑通再扩大：
- 选一个低风险、最好是只读的 server 作为起点。
- 配置好后，用
app mcp status --json确认它已连接、工具已暴露。 - 把它只启用给一个测试 Agent，不要先铺给所有 Agent。
- 在该 Agent 里给几个简单任务，观察它如何选择和调用工具。
- 通过可观察日志回看实际的调用参数和返回，确认行为符合预期。
- 确认稳定后，再考虑放开更多能力或挂到其他 Agent 上。
MCP 的价值不在于一次接很多，而在于让能力的扩展变成可控、可检查的步骤。从一个 server、一个 Agent 开始，你会更清楚每一项工具到底为你的工作流带来了什么。