Stream the interface,
not the page.

The protocol is small enough for a language model to write as it goes. In the generator you describe an interface and a model streams it as XUL-J, one JSON line at a time. Every line is checked against the schema before it is rendered, so you watch the UI assemble itself, and anything malformed is rejected rather than displayed.

Then the model becomes the app's backend. Typing stays in your browser. Clicking an action sends {"do":"cmd_add","inputs":{…}}, and the model answers with operations that update rows, totals and messages, or open a confirmation dialog. You can also ask for changes in plain words.

An interface streamed as XUL-J is already what an agent needs: a labelled tree with explicit commands, enabled and disabled state, tables and dialogs. The XUL-J MCP server hands that tree to any MCP client. Put it in front of a bridge, and a 2005 WinForms or Swing app becomes something an agent can operate reliably: no screen scraping, no clicking at coordinates.

claude mcp add legacy-orders -- \
  node xul-j/mcp/server.js --url http://127.0.0.1:8092

// do_command cmd_addButton
+ label "Customer is required." [errorLabel] (danger)
~ label "Order not added" [statusLabel]

// open_context_menu ordersGrid
item "Duplicate order" [duplicateItem] → cmd_duplicateItem
item "Delete order…" [deleteSelectedItem] → cmd_deleteSelectedItem

// do_command cmd_exportItem, then Save
~ label "Exported 1 orders to agent-export.csv" [statusLabel]
~ enabled again: file, edit, help and 14 more

The server sends operations, one JSON object per line. Each one is valid on its own, so a cut-off stream is never a broken document. It is just a shorter one.

// server → client
{"op":"command","id":"cmd_deploy","label":"Deploy","key":"ctrl+enter"}
{"op":"node","in":"root","tag":"window","id":"win","label":"Deploy console"}
{"op":"node","in":"win","tag":"toolbar","id":"tb","children":[
  {"tag":"toolbarbutton","command":"cmd_deploy"}]}
{"op":"node","in":"win","tag":"pending","id":"log","hint":"tree","flex":1}
{"op":"replace","id":"log","tag":"tree","rows":{"source":"log"},…}
{"op":"rows","source":"log","append":[{"t":"12:01","msg":"build ok"}]}
{"op":"broadcast","id":"busy","value":true}

// client → server
{"op":"do","command":"cmd_deploy"}
{"op":"input","id":"filter","value":"error"}

XUL already had the right ideas, and each one turns out to suit streaming:

Stable ids and overlays

Every element can be addressed, so anything can be patched later. A node whose parent hasn't arrived yet simply waits for it.

Commands

Intents are separate from widgets. Disable cmd_deploy once, and its button, menu item and shortcut all follow.

Broadcasters

Named values that attributes observe: observes: {"disabled": "busy"}.

Boxes and flex

A half-arrived layout still looks reasonable, and a pending placeholder holds space until its widget arrives.

Themes as tokens

A producer can send colours, radius, density and font, never CSS. The viewer's dark mode, contrast settings and WCAG checks win.

Data apart from structure

A tree is declared once and rows stream into it. 100,000 rows render as about 30 DOM nodes.