MCP began as a protocol for a model to talk to tools. The model asks a server what it has, calls a tool, gets a result. People were outside that conversation, and when a screen was needed it came back as text.
As tools multiplied, text stopped being enough. A table had to be shown, a map had to be drawn, a button had to be pressed. A window was needed.
This is where it splits. There is not one kind of window.
Window ① — the one a model shows a person
In November 2025 the MCP-UI community and OpenAI's Apps SDK were solving the same need separately. The two merged into MCP Apps (SEP-1865), which reached Final as the first official extension to MCP.
The structure is this.
- A server pre-declares UI resources under the
ui://scheme - A tool references that resource through metadata
- When the tool is called, the host renders HTML in a sandboxed iframe
- The iframe and the host talk both ways
- When the UI calls a tool, user consent is taken
It is a well-designed specification. Pre-declaration lets a host fetch, cache and review ahead of time; the iframe sandbox isolates UI from servers you cannot trust. The decision to handle HTML only is a clear one — it runs everywhere, the security model stays simple, and screenshots can be produced.
This window belongs to the model. Mid-conversation a tool is called, and the result appears as a screen. The conversation got more expressive.
Window ② — the one where a person handles a machine directly
But there is this scene.
A ship's wheelhouse. Engine state, fuel, ballast, generators. The chief engineer works the console directly. The captain watches instruments on a tablet. The deckhand gets alarms on a phone. Same equipment, different screens, different authority.
There is no model here. Having one is better — something that says "generator 3 has been climbing for fifteen minutes" first is better. But the ship sails without it. The engineer reads the gauge and takes the valve.
The control panel of a special-purpose vehicle, the implement controls on farm equipment, the operating panel of a factory line — all the same. A window where a person handles a machine directly. Not the output of a tool call; the operating surface itself.
This window was never what MCP aimed at. But MCP already holds the materials for it — a device exposes its functions as tools, publishes its state as resources, announces changes. What is missing is the screen.
Why window ① cannot make window ②
Not a matter of better or worse. A matter of design premises — and all four are written in the MCP Apps specification.
First, HTML and an iframe are requirements. The render target is HTML and sandboxing is mandatory, not optional. A microcontroller with tens of kilobytes of RAM has no HTML engine. It has no iframe either. Where a device must draw on its own LCD, that requirement is a wall.
Second, a tool must be called for the UI to appear. The loop is model → tool → UI → user. Remove the model and the window does not open. A wheelhouse console has to be on when the ship has power.
Third, there is no axis called channel. "This machine gives control at the wheelhouse and read-only on a phone" — there is nowhere to express that distinction, because the host that opens the window is one.
Fourth, the threat model points the other way. What MCP Apps guards against is "an untrusted server sending malicious UI into my chat client". What device control has to guard is "who is allowed to operate this machine". The former protects the user; the latter protects the machine and the people near it.
The two windows are not in competition
MCP Apps is the window a model shows a person; a device control face is the window where a person handles a machine. Remove the model and the first disappears; the second runs without one.
And the two can sit on the same screen. A model says an anomaly is developing and puts up a trend chart (window ①), while beside it the engineer works the valve directly (window ②).
That is the picture the designer described too — that he took the channel where the model talks and made it a window a person can talk through as well, and that you can also look at it together.
That is the second axis
The first axis asked, at the business layer, who owns the business. The second asked, at the protocol layer, who owns the window. Different layers, so neither answer cuts the other.
From the next piece it is screens. What it actually means that a device serves its own screen — confirmed on two boards sitting on a desk.
makemind.dev "Horizon" — Everything said about MCP Apps here was checked against its own specification.