Apps

A tool with a screen

Most work an agent does comes back as words. Some of it should not: a file has to go up, a date has to be picked, a total has to be checked before money moves, one of three hundred rows has to be chosen. An MCP App is a tool that brings its own small interface and opens it inside the conversation.

This is not Inline’s invention. MCP Apps is a published extension to the Model Context Protocol, SEP-1865: a tool may declare an HTML resource under a ui:// URI, and a host that supports it renders that HTML in a sandboxed frame inside the conversation, talking back to the server over the same connection. What Inline adds is a way to get one without a front-end project.

How Inline makes one

A saved tool in Inline is a script plus a description and an input schema. If it also carries a template, it is a panel tool. When it runs, the template is filled with the value the script returned, and the host shows the result as a panel.

The template is written by the model that built the tool, so it is rendered in a sandbox with escaping on. It fills in values and nothing else: it cannot reach attributes or call anything the sandbox forbids, and the only values it sees are the script’s own return data, which has already been through the governed path. A tool from a connected source that declares its own ui:// resource is an app in the same sense, rendered the same way.

A panel tool is run with execute_panel rather than run_tool. Search results mark it, and if it is run as a plain tool anyway the result says so, so an assistant can correct itself and show the panel.

Previewing one

A panel tool saved in Inline has a preview page, reached from the apps list on Servers. It shows the panel drawn, beside the values it is drawing, filled with made-up data so the first look is a filled-in screen rather than an empty one. A panel that came with a connected source cannot be previewed there — it belongs to the server that serves it. You can edit any field, add or remove items from a list, or paste the values as JSON, and draw it again.

The preview also says who saved the tool, which version this is, and which server it belongs to. If the tool has buttons, it names the tools those buttons run — they run with the permissions of whoever uses the panel, and they do nothing in the preview, because a panel only acts inside the application that opens it. A tool with no template says so plainly: it answers with plain data and there is nothing to preview.

Where it renders, and where it does not

MCP Apps is new, and not every host renders one. A tool built here works either way. Where apps are supported, the screen opens in the conversation. Where they are not, the host calls the same tool, gets its data as text, and the assistant asks for anything missing in words. There is nothing to build twice.

The panel runs in the host’s own sandboxed frame and is filled by the result of a call that already passed the server’s tools, keys, behaviour ceiling and rules. Giving a tool a screen does not widen what it may do.

The Apps page

Apps is also the name of the page where a workspace adds a process somebody else published. That is a different thing from a panel — it is an installed tool, bound to your own sources and running under a grant you ticked — and it is described under publishing. An installed app may carry a panel too, in which case both descriptions apply to it at once.