The same question kept coming back.
"So how is that different from X?"
Nobody asks it in bad faith. There are already plenty of things that put screens on devices, and we put screens on devices. From the outside it looks the same.
The awkward part was our end. We could explain what we do. We could not say in one sentence what is different. The more features we listed, the more we heard "well, they do that too."
It only came into focus after looking closely at something that resembles us. The resemblance was not one kind.
Two things resemble this, at two different layers
The first is a platform that runs apps inside a device. Automotive infotainment, a smart-TV operating system, a home hub. There is a runtime, there are authoring tools, there is a store. We say those three words too, so we overlap.
The second is a window a model opens mid-conversation. That is MCP Apps (SEP-1865), which reached Final as the first official extension to MCP. A tool is called, and the result appears as a screen. We also talk about screens on top of MCP, so again we overlap.
But those two do not resemble each other. One is the shape of a business; the other is the shape of a protocol. They sit at different layers.
So "how is that different" was really two questions. Trying to answer with one is why no answer came out.
Changing the question
Answering with features loses. They draw screens, they run apps, they call tools. All true.
So this volume asks something else.
Not what it does — who owns it.
Ask it that way and each layer produces its own answer.
To a platform that runs apps inside a device — who owns the business. In that structure the party that makes a business is the one that owns the device. It opens the store, reviews what goes in, sets the cut. Growth is measured in how many units ship.
To a window a model opens — who owns the window. In MCP Apps the thing that opens the window is the model. A tool is called mid-conversation and the result becomes a screen. Remove the model and the window does not open.
Neither question asks which is better. Both ask where each one stands. And when the standing is different, what is possible and what is not separate on their own.
The order this volume answers in
Fourteen pieces. The first few set the two axes; the rest pay them off on screen.
We asked the designer directly. What he answered when the question came, and what he could not answer. And the four most common misreadings, corrected in his own words.
Axis one — the garden and the ground. Who makes the business. Here growth is not units shipped but how many domains get on. And as a consequence, the platforms we just called "similar" turn out to be a way through rather than a rival.
Axis two — there are two windows. What MCP Apps is, described as its own specification describes it, and where four design premises part ways. Also that the two windows can sit on the same screen.
Everything after that is real. A device handing over its own screen. There being no such unit as an install. Adding one more device without the host changing. Opening the same machine at different permission grades per channel. And whether the same structure holds when the trade changes, across four floors.
The last piece states where we stand.
Stated up front
This volume does not diminish either side. MCP Apps is a well-designed specification, and we wrote it so that its own authors would read our description and find it correct. The platforms that run apps inside devices hold twenty years of work, and we are the ones trying to get inside them.
And we do not say this is easy. It is not. You have to know the specification to use it, and hiding that would spend, in one sentence, everything this magazine has built in six months. It is not easier — it is owned differently.
The next piece asks the designer directly.
makemind.dev "Horizon" — The other thirteen pieces in this volume pay off these two axes one at a time.