Most MCP tool results are text. The model calls a tool, gets back a string or a block of JSON, and turns that into a reply. MCP Apps, one of the two extensions introduced alongside MCP’s 2026-07-28 spec update, changes that for servers that opt in: a tool result can render as actual interface inside the conversation, not just a wall of text the model has to describe back to you.
What actually changes
Without MCP Apps, a server that wants to show you, say, a form to fill in or a table you can sort has one option: describe it in text and hope the model renders something useful, or make you leave the conversation to a separate web page. MCP Apps gives a server a second option — ship UI as part of the tool result, so the client can render it directly where the conversation already is. A tool that books a meeting could return an actual date picker. A tool that touches billing could return a real confirmation dialog instead of a paragraph asking you to reply “yes.”
That’s a genuine extension of what MCP result types could do before, but it’s still early: it’s a spec extension a server has to explicitly build against, and a client has to explicitly support rendering. Whether your client shows an interactive widget or a plain-text fallback depends entirely on whether both sides implemented it. Check your specific client’s release notes before assuming it’s live.
Why this is a bigger deal than it sounds
The obvious read is “nicer-looking tool results.” The more interesting read is what it does for approval flows. We wrote about the general problem in human-in-the-loop approvals for AI tool calls: today, most consequential actions get gated by a text prompt asking you to confirm, and text prompts are exactly the kind of thing people stop reading after the third or fourth one. A rendered UI — a real button labeled “Send” next to the actual email it’s about to send, instead of a sentence describing it — is a different kind of friction. It doesn’t guarantee anyone reads it more carefully, but it at least gives the client somewhere to put a real, unambiguous control instead of relying on the model to phrase a confirmation clearly enough.
It also matters for anything with a spatial or visual shape that text has always struggled with — a calendar, a spreadsheet-like grid, a diagram, a set of options laid out for comparison. Servers doing those things today usually push you out to their own web app. MCP Apps is the extension point that lets that stay inside the conversation instead.
What it means if you build a server
Nothing about MCP Apps is mandatory. Plain text and structured JSON results still work, still cover most tools, and still don’t need a client that supports rendering UI. It’s worth reaching for only when a tool result genuinely benefits from an interactive surface — picking a date, confirming a specific record before a write, comparing a small set of options — not as a default way to make results look nicer. If you’re generating a server from an existing API with a tool like gate’s MCP server builder, an OpenAPI spec doesn’t carry any of this UI information on its own; MCP Apps is a deliberate addition on top of the generated tool surface, the same way we noted sampling is, not something that falls out of a spec conversion for free. See turning an API into an MCP server for the more common, UI-free path most servers still take.
What it means if you use MCP servers
Rollout is gradual and dual-version, same as the rest of the July update: some servers will ship MCP Apps support, most won’t for a while, and clients will keep falling back to plain results for anything that doesn’t render. Day to day, the main thing worth watching for is what a rendered UI is actually asking you to approve. A confirmation button embedded in the conversation is still a tool call underneath it — the same access and consequences apply whether the approval you clicked was a sentence or a button. “It looked like a real app” isn’t a substitute for knowing what the tool underneath it is allowed to do.
The bottom line
MCP Apps lets a server return real interface — forms, pickers, confirmations — instead of text the model has to describe. It’s an opt-in extension both the server and the client have to support, it’s early, and it doesn’t change what a tool call is allowed to do underneath the UI. Worth watching for anything with a genuinely visual or interactive shape; not a reason to expect every tool result to look different tomorrow. Browse gate’s MCP server directory for what’s actually shipping today.