设备把画面递过来 — 两块板各自给出自己的定义

上一篇说窗有两扇，人直接操作机器的那扇不是 MCP 原本瞄准的位置，而且缺的是画面。

这一篇讲那份画面从哪里来。

换掉一个前提

通常是宿主知道画面。哪台设备给哪个值、这个值用哪个组件画、哪个按钮发哪条命令 — 应用全知道。所以多一台设备就改一次应用。

要换的前提是：画面由设备定义，不由宿主定义。

设备本来就作为 MCP 服务器把自己的功能暴露为工具。再加一件事 — 用声明的方式描述自己的画面。 客户端接住这份描述，用原生方式画出来。不需要浏览器，也不需要内嵌网页引擎。

于是客户端不必事先知道要画什么。第一次见到的设备，接上就能操作。

桌上的两块板

这话说出来很像那么回事，正因如此才用实物确认。

两块板。STM32H723 走 USB 串口，ESP32 走 Wi-Fi。连发现方式都不同 — 一个靠打开端口找，一个靠网络找。无论电气上还是传输上，两者毫无关系。

每块板上有桥接，把自己的功能暴露为工具，把自己的画面暴露为资源。而客户端对两者完全相同，没有按板分支。

画面出来了。按下按钮，桌上的 LED 真的亮起来。

这个样例挂着一条规则：没有板子就不算通过。 不用仿真替代，而是报出查了哪个端口然后判失败。没有硬件却「验证」过的硬件文章，不算验证过。

抓到的一件事 — 板子是对的

做这个样例时，真板曾经当场死掉。读资源列表的一瞬间就因类型错误崩了。

原因不在板子。是客户端库违反了规范。 资源的描述字段在 MCP 规范里是可选的，而库把它当成必然存在的值来读。没写描述的板子是合规的，读的那一方错了。

用同一个库的另外四个样例没读那个列表，所以没事。这是只有接上真实硬件才会显出来的位置。

画面本身就是逻辑

说「把画面送过去」，听着像只递一张图。不是。

描述里同时装着三样东西。

• 绑定 — 设备的状态流进画面的值
• 动作 — 状态变更、工具调用、成组执行，以及条件分支
• 订阅 — 持续接收设备的状态变化

把这三样编在一起就成了控制。订阅温度节点的值，让它流进画面，条件分支判断阈值，再调用风扇节点的工具。只要分别接上传感器和风扇，不用写把两者连起来的代码。

不是为了控制去学另一门语言。声明画面，控制就跟着来。

到这里是一台设备

一台设备递出自己的画面，而那份画面就是操作面。

现场很少只有一台设备。驾驶室里发电机、压载和燃油在一起，温室里传感器和阀门在一起。

把多台设备汇到一屏，是两篇之后的事。在那之前，先写这个结构里没有「安装」这个单位。