Skip to content
SavoiaGuide

MCP apps

An MCP server can return not only text but an interface: a ready page the host shows instead of a tool result and then talks to. In a chat that becomes a picture inside the conversation. Here an app is a tab, level with a website: it can be moved, carried to another group, left open and come back to tomorrow.

It cost Savoia nothing: every window already has its own content process and its own storage, which is a stronger sandbox than an iframe.

Server settings

Open Configuration ▸ Assistant ▸ MCP. There is no separate Apps menu.

  • Connected Servers — addresses, status and Agent Access switches. Editing, connection checks, sign-in and Open App are in each server’s “…” menu.
  • Browse MCP Catalog… — a separate window with registry search and the catalogue of servers with interfaces.
  • Add Server… — connect by command or URL. Ordinary MCP servers without interfaces are configured here too.

On macOS, the separate savoia://apps page has been removed; configure servers here.

Where apps come from

There are many catalogues of MCP servers and not one catalogue of the servers that draw something — the registry schema has no field to filter on. The only way to know is to connect and look, so Savoia builds that list itself: it walks the official registry, asks every remote server, and writes down the ones that have an interface.

The first full sweep, 30 August 2026: 25,772 servers in the registry, 13,555 with an HTTP endpoint, all of them asked, an interface found in 308 — and 1,374 tools in them that draw a window.

The app catalogue and live registry search are available in the MCP Catalog window.

Package servers (npx, uvx) are not run during the sweep: downloading and executing somebody’s code to find out what it does is not what the person who opened the panel signed up for.

Signing in

The panel probes remote servers without authorization — so that a search never opens a sign-in window for anybody — and reports what it found: “39 of 39 have an interface”, “sign-in required”, “did not answer”.

The Sign In button appears only for a server that refused without a token, and for nobody else: offered to everyone, it would stop meaning anything. Signing in by hand is always possible through the row’s context menu. A local server is never asked: it is a process the browser started itself.

Your own servers

Add Server… takes either a local command (run in your shell’s environment, so nvm and homebrew work) or an HTTP address. A token, if one is needed, is sent as a bearer. To change a server already added, use Edit… in the row’s context menu.

A local server that wants an API key reads it from its environment: add it under Environment with Add Variable — KAITEN_TOKEN on the left, the token on the right, as it is, no quotes. A NAME=value line from a .env file or a README pasted into a name field is split into rows by itself. A server added from the catalog whose publisher declared such variables opens this form first, with the names already filled in; one left empty is not passed at all, and the server’s row says Not set: and the name.

OAuth client

Signing in usually needs no setup at all: the browser registers itself with the server at the moment a sign-in is needed. Some providers hand out no clients that way — theirs are created by hand in a console, and there is no registration endpoint at all. Google’s official Workspace servers are the case in point. For those, the server’s form has an OAuth client section:

  • Client ID and Client secret, from the provider’s console. The secret is kept in the Keychain rather than in the settings.
  • Scopes, space-separated, for a server that does not say which it needs.
  • Issuer, only when the server names none itself (https://accounts.google.com for Google).
  • Redirect URI — copy it and register it with the provider exactly as shown: the sign-in comes back to it. It is stable, derived from the server’s name, and does not change between launches.

When an app calls a tool

An app inside a tab can ask the browser to run a tool of its server. That is put to a person — a bar above the page — and the answer is remembered for the life of the tab.

A tool the server has not declared safe to repeat is never re-run by Savoia on its own.

What is given to the agent

A shared server’s tools reach the agent as the browser’s own, and then the agent opens app tabs itself: ask about the weather and get a weather tab rather than a paragraph. The agent’s tool list is live: share a server or take it back, and it finds out at once.

App windows are visible to the agent like pages: it can list them, read them and take a screenshot of them.