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.

One thing that was caught — the board was right

While building this, a real board died instantly. It fell over with a type error the moment the resource list was read.

The cause was not the board. The client library was violating the specification. A resource's description field is optional in MCP, and the library was reading it as always present. The board that shipped no description was within spec, and the reader was wrong.

Four other samples on the same library never read that list and were fine. It is a spot that shows only with real hardware attached.

The screen is the logic

"Serving a screen" sounds like handing over a picture. It is not.

Three things travel inside the description.

• Bindings — the device's state flows into the screen's values
• Actions — state changes, tool calls, batched runs, and conditional branches
• Subscriptions — the device's changes keep arriving

Weave those three and you have control. Subscribe to a temperature node's value, let it flow into the screen, let a conditional branch judge the threshold, and call the fan node's tool. Attach the sensor and attach the fan; nothing is written to join them.

You do not learn a separate language for control. Declare the screen and control follows.

That is one device

We have a device handing over its screen, and that screen being the operating surface.

Sites rarely have one device. A wheelhouse has generators and ballast and fuel together; a greenhouse has sensors and valves together.

Gathering several devices onto one screen is two pieces away. First, this structure has no such unit as an install.