u/tribat

I’ve wanted a “take control” option from ADSB app for a while. I’m finishing up a big travel related app with Claude Code, and there’s a lot of sitting around waiting for it to finish a chunk. I started tweaking an Adsb app to see what’s possible for flight sim in a browser. Turns out quite a bit.

Try it here https://fly.voygent.app (Cloudflare hosted, no signup required). Run it yourself as local dev, docker image, or cloudflare worker: https://github.com/iamneilroberts/SQUAWK

It’s usable on browser or mobile (fullscreen landscape is best). I plan to keep working on it to pass the time so submit any bugs or improvement ideas.

Title: A runnable MCP Apps example repo: Rich html "app" UI in Claude chat flow.

---

I built an MCP App that renders an interactive widget inside the chat (Claude, web and Desktop). I put together a small runnable example repo and some docs covering the parts that took me a while to figure out from the spec alone. Posting it here in case it's useful.

Repo: https://github.com/iamneilroberts/mcp-apps-interactive-ui (MIT)

Quick background if you haven't tried the Apps extension yet: MCP Apps (io.modelcontextprotocol/ui, SEP-1865) lets your server return a sandboxed HTML widget instead of text. The model calls a tool, the host renders your widget in an iframe, and the widget talks to your server over a postMessage bridge. Spec and SDK: modelcontextprotocol/ext-apps.

The example

The repo's example app is a Pizza Builder. Pick size, crust, and toppings, watch the price update live, hit "place order" and it hands the selection back to the model. It runs (npm install && npm run build && npm start), connects to Claude Desktop over stdio, and the built widget also opens directly in a browser with mock data so you can see it without a host. It has unit tests and a CI workflow if you want to verify before trusting it.

[screenshot: pizza-builder.png]

It's deliberately a boring domain so the MCP Apps mechanics are the only thing you're looking at.

The pattern worth copying: keep the payload out of the model's context

This is the thing I'd tell anyone starting an MCP App. A rich widget needs a lot of data. If you return that data from the tool the model called, it lands in the model's context every time, which gets expensive.

The fix is a reference-and-fetch split:

1. The launcher tool the model calls returns a tiny reference, just an id.
2. The widget fetches the full payload itself by calling a second tool over the bridge.
3. You hide that second tool from the model with _meta.ui.visibility: ["app"], so it never appears in the model's tool list and never costs a token.

One thing that tripped me up: visibility: ["app"] hides the whole tool, it does not gate per-result content. There's no app-only channel inside a single tool result. So you genuinely need two tools, one model-visible launcher returning the ref and one app-only data tool. In one app I built, this took the model-visible payload from about 9,000 tokens to around 130.

A related point: visibility: ["app"] is a hint the host honors to keep the tool out of the model's list. It is not access control. The tool still exists in the protocol, so a raw MCP client can list and call it. Validate its inputs server-side anyway.

Probing what the host actually grants you

Capabilities and context vary by host, and you can't read them from a shell, only from inside a live session. So I built a probe app that dumps getHostCapabilities() and getHostContext() and renders them, then ran it.

Claude Desktop (Claude/1.569.0, 2026-06-13):

Capability	Result
openLinks	yes
downloadFile	yes
logging (sendLog)	yes
updateModelContext	yes ({text, image})
message (sendMessage)	yes ({text})
serverTools / serverResources	yes
sampling	no
app-registered tools (model→app)	no (onlisttools/oncalltool never fired)

Context on Desktop: inline plus fullscreen display modes (no pip), container width fixed at 736px with height up to 5000, dark theme, full set of ~76 CSS theme variables plus the host font. I haven't captured the claude.ai web capability numbers in-host yet, so I'm not claiming them.

The gotchas

Full writeups are in the repo's docs/08-gotchas.md. Short version:

1. Claude caches ui:// resources by URI and doesn't refetch on reconnect. Ship a new widget and connected web clients keep rendering the old one. Put a hash of your widget bundle in the URI so a new build changes the URI. On web you still need a fresh chat; Desktop refetches.
2. The tool catalog is locked per session. Register a new tool and existing sessions won't see it until they reconnect. There's no tools/list_changed on claude.ai.
3. updateModelContext is silent. It stages state for the model's next turn, it does not trigger a turn, and it keeps only the last update. To actually hand control back you call sendMessage after it. Also: capabilities are on getHostCapabilities(), not getHostContext(). I lost time to that one.
4. sendMessage on claude.ai web shows a red "use caution" banner every time, whatever the wording. It's host safety UX and you can't turn it off. Design the flow assuming it's there.
5. No progressToken from claude.ai. MCP progress notifications never arrive. The only live "working on it" feedback is the model narrating.
6. claude.ai stringifies nested object params passed to your app-only tools. Coerce them server-side (I use z.preprocess with a JSON.parse).
7. The default sandbox CSP blocks external images (img-src 'self' data:). Declare _meta.ui.csp.resourceDomains with the exact origins you need. claude.ai web and Desktop both honor it.
8. Sandboxed iframes can't window.open. Use app.openLink.
9. Inline width is fixed around 736px. Design to it. Height is flexible.

A small tip

The spec repo (modelcontextprotocol/ext-apps) has the full SDK source, the schema, and about a dozen example servers. I cloned it locally and keep it open while building, since the host API surface is easier to read from the source than to remember. The examples directory is the fastest way to see a correct minimal server.

Happy to answer questions. If you've captured the claude.ai web capability numbers, I'd like to compare.

Repo: https://github.com/iamneilroberts/cueframe
Example: https://demo.voygent.ai/

I was working on my web app personal project and trying to create some kind of demo animation or video...or something. I tried several apps, and it just wasn't working. By actual accident I prompted Claude Code to build a one-off tool that conversationally creates a demo of a web app.

To explain: my app runs as an MCP custom connector inside Claude, so to simulate it I built a website that looks like Claude but uses API calls to stand in for the LLM in the chatbot app. I damn near lost my mind trying to get a usable screen recording video. Then I pointed CC at my app on the web and told it I wanted a simulation of a user interacting with it and a call-out for the cool stuff.

It proceeded to build a new web page that ran an animation of using it, and when I thought to ask, gave me frame numbers of each interaction. I went on to build a demo way better than expected. The crazy thing to me is that I just said "put a call-out near the hotels about merging results" and it...just DID it.

Later I realized I had the makings of a decent tool. So I went back to that session and ask it for a prompt for a new session to build a github-ready repo based on what we had done there. I pasted that prompt into an empty session/repo and set it to auto mode.

About 35 minutes later (Max 20x Opus 4.8,"cost" ~$38) I had the result in the link. I had it run on two other websites and post the results in the Readme. I'll be honest: I use claude code and only really read the PRs so I'm not 100% sure this is worth a tinker's dam(n).

Let me know if you find it useful.