MCP Apps: the new surface your fleet inventory misses

The July 28 Model Context Protocol (MCP) spec made servers interactive. Most fleet operators inventory tools and schemas. Almost none inventory UIs. That gap is the next six months of incidents.

The 2026-07-28 spec release candidate introduces MCP Apps: an Extensions-framework capability that lets a server ship interactive HTML and have the host render it in a sandboxed iframe. It is a real upgrade to how MCP feels to use. It is also a new surface that runs code in your users' client context — and unlike a tool call, most of what it does never crosses your gateway or your logs.

What MCP Apps actually is

MCP's Extensions framework lets the protocol grow named, opt-in capabilities without bloating the core. MCP Apps is one of those extensions. A server declares one or more UI templates; when a client that supports the extension connects, the host renders that interactive HTML inside a sandboxed iframe alongside the raw tool calls.

The motivation is straightforward: richer host experiences without every server bolting a bespoke UX layer onto plain tool responses. Instead of returning a wall of JSON for a human to squint at, a server can ship a small interface the host presents directly. For end users, that is a genuine improvement.

Why this is a governance surface, not just a UX feature

The moment a server can ship a UI, it can ship code that runs in your users' client context. That reframes MCP Apps from a UX nicety into an operational surface you now have to account for.

• Sandbox is not trust. Iframe isolation caps the blast radius of a misbehaving UI. It says nothing about what the template contains, what it calls, or who authored it.
• Visibility drops at the iframe boundary. Your gateway and server-side logs see the tool traffic; the interesting behavior of an interactive UI happens client-side, where most fleet tooling has no instrumentation.
• Adoption will outrun review. UI templates are the shiny new capability, so teams will turn them on. The question is whether anyone is tracking which servers did.

The three questions your inventory should answer

If MCP Apps is an operational surface, these are the operational questions that decide whether a bad template is caught in review or discovered in an incident.

• Inventory: which servers in our fleet declare UI templates today — including the one a single team enabled last week?
• Change: which server gained a UI since the last audit? A server that shipped only tools yesterday and renders an interface today is drift you want to see.
• Provenance: who approved that template, and against which version of it? 'It was fine when we looked' is not an answer once the template can change under you.

Most teams can answer the first question with a guess and the next two with a shrug. That is the gap MCP Apps just widened.

The pattern MCP keeps repeating

This is the same movie the ecosystem has already watched twice. A capability ships, adoption outruns visibility, and security retrofits controls after the first incident instead of before it.

We saw it with the move from sticky sessions to stateless transport, where the scaling win quietly changed what audit trails could see. We saw it with poisoned tool descriptions — the surface Microsoft flagged in mid-2026 — where the exploit lived in content most teams never inspected. MCP Apps is the next entry in that pattern. The teams that come out ahead are the ones who treat it as inventory before it becomes an advisory.

What good looks like

Handling MCP Apps well does not require a new security team. It requires treating UI templates as first-class inventory, the same way you already treat tools and schemas.

• Track UI templates as an inventory attribute on every server, right next to its tools and auth posture.
• Diff templates across versions and alert on new-UI drift — a server gaining or changing a UI is a reviewable event, not a silent deploy.
• Tie approval to a versioned Server Card, so 'who signed off on this template, and which version' is a lookup instead of a hallway conversation.

That is the layer MCPOrbit is built for: fleet-wide visibility into every MCP server you run and what it exposes — now including whether it ships a UI, and whether that changed since you last looked. Centralized auth decides who gets in. Fleet observability decides whether you would even notice a new surface appearing inside the door.