The Device Hands Over Its Screen — Two Boards, Each Giving Its Own Definition

The last piece said there are two windows, that the one where a person handles a machine was not what MCP aimed at, and that what is missing is the screen.

This piece is about where that screen comes from.

Change one premise

Normally the host knows the screen. Which device gives which value, which widget draws it, which button sends which command — the app holds all of it. So when a device is added, the app is edited.

The premise being changed is this. The screen is defined by the device, not the host.

A device already exposes its functions as tools over MCP. One thing is added — it describes its own screen declaratively. The client receives that description and draws it natively. No browser, no embedded web engine.

Then the client does not need to know in advance what it will draw. A device it has never seen can be operated the moment it attaches.

Two boards on a desk

Said out loud this sounds plausible, which is exactly why it was confirmed on hardware.

Two boards. An STM32H723 attaches over USB serial; an ESP32 over Wi-Fi. Even discovery differs — one is found by opening a port, the other by looking on the network. Electrically and in transport they have nothing in common.

Each board has a bridge that exposes its functions as tools and its screen as a resource. And the client is identical for both. There is no per-board branch.

The screen comes up. Press the button and an LED on the desk actually lights.

That sample carries a rule: if the board is not there, it does not pass. No substituting a simulation — it reports which port it looked at and fails. A hardware story "verified" without hardware is not verified.