新物先用一个问题分清回答和操作
问“音量调低有什么好处”，模型给出文字回答即可；说“把这台设备音量调低”，还需要有一个能实际改变音量的能力。MCP 为模型发现和调用工具提供一套约定，但协议本身并不会替一块没有相应功能的板子补出硬件。
设备可以作为语音入口，真正执行动作的位置却可能不同。先弄清工具在哪里运行、能访问什么，再找接入方法，比先复制一个地址到控制台更容易理解问题。
参考：[1] 官方教程：小智 MCP 接入点说明[2] v2.5.2 文档：设备端 MCP 工具用法[3] v2.5.2 项目说明：设备端与云端 MCP
设备端工具与智能体接入点，各自扩展什么
设备端工具由固件注册，后端可以发现并调用它们。例如项目文档列出的设备状态、扬声器音量等，具体可用项取决于板型与编译配置。摄像头或屏幕工具也有硬件与功能条件。
官方 MCP 接入点说明则描述把外部 MCP 服务连接到智能体，让语音终端使用其能力，例如计算、查询或其他外部系统操作。它不等于把每个工具都装进 ESP32，也不是换了角色名字就自动获得外部服务。
| 你想做什么 | 优先确认什么 |
|---|---|
| 读设备状态、调整扬声器音量 | 固件是否注册并允许调用对应设备端工具。 |
| 让智能体使用计算或查询服务 | 外部 MCP 服务是否运行，并连接正确的智能体接入点。 |
| 控制额外硬件 | 实际硬件、驱动、固件工具与权限是否齐备。 |
参考：[1] 官方教程：小智 MCP 接入点说明[2] v2.5.2 文档：设备端 MCP 工具用法[3] v2.5.2 项目说明：设备端与云端 MCP
一次工具调用，可以拆成四个观察点
设备端文档描述的典型过程，是设备先与后端连接，再初始化 MCP 会话，后端获取工具列表，随后调用某个工具并接收结果。工具的名称、参数与返回值要符合实际注册的定义。
因此，“模型说已经做了”与“工具确实执行成功”需要分开检查。先看工具是否出现在可用列表，再看是否发生调用、参数是否正确，最后检查返回结果和实际状态。复杂问题也能据此缩小到一个环节。
- 确认设备或外部服务已连接到预期的后端或智能体。
- 确认目标工具确实可见，并读懂它的输入与返回结果。
- 提出一个明确、单一的请求，观察是否发生工具调用。
- 将工具返回结果与实际状态核对，而不是只听模型的口头回答。
- 做到这里，你应该看到
- 能指出工具是否被发现、是否被调用，以及结果是否符合预期。
第一次扩展，选结果容易核对的任务
如果准备接外部服务，可以先选一个你能手算核对的计算任务。按照所选服务和官方接入说明配置，让服务连接到正确智能体，再提出固定问题，检查调用与结果。没有自己的接入点时，先完成账号和智能体准备。
官方文档的接入点来自智能体配置，当前入口位置可能变化；本篇没有登录复核。下图仅为创建智能体的历史示例，不是当前 MCP 配置页。不要把图片里的位置当成现有控制台按钮路径。
- 做到这里，你应该看到
- 一个指定工具完成了可核对的任务，且知道它连接的是哪个智能体。
工具越能做事，越要读清执行边界
接入点及其中的凭据应按服务说明保存，不公开贴到截图里。先用可观察、可撤销的任务熟悉流程，再考虑外部系统的写入动作；工具可用并不意味着每个请求都应该自动执行。
v2.5.2 文档还区分普通工具与 user-only 工具，后者用于不应由模型自主触发的用户操作。工具名称出现在文档里，不代表你当前设备和后端已经开放它。以实际可用列表、配置与执行结果为准。
资料来源与版本说明
本文属于小智现成固件路线，按文末官方资料与固定源码复核。历史 Q&A 与旧界面仅用于其所注明的版本情境，具体动作再按固定源码与板型核对；当前控制台的登录后界面和实物操作尚未验证。资料核对日期：。资料核对、程序构建与实板测试分别记录，不互相替代。
飞书原文请在浏览器打开；如跳转到登录页，按飞书提示访问。历史截图的原图出处与当前工具入口分别标明。
