The screens

The Studio’s left sidebar is one link per feature. Each screen drives one slice of the server’s /api/* surface, and every screen renders its own loading, empty, and error states rather than a blank page. This page tours the surfaces you reach most.

​

Tools

The Tools screen lists every tool the manifest loaded — your own functions, mounted MCP servers, the standard toolbox, and any extension variants (a _batch or _chain branch appears as its own runnable tool). Select one to open its run panel. Running a tool has two modes — a synchronous run and a detached background run. Running tools covers the trade-off in full.

​

Templates

The Templates screen browses the stored resources the ResourceManager serves — jinja templates and other content held in the configured storage backend. Select one to view and render it; the upload form writes a new resource.

​

Dashboard

The Dashboard reads the server’s monitoring backend — run counts, cost, latency, and token totals over a time range, with a per-model breakdown and a trend chart. The demo instance below is populated from a monitoring backend seeded with example runs; with no backend registered, it renders a clean empty state instead.

​

Marketplace

The Marketplace screen browses the marketplace plugin index through the server. A Browse tab runs an item-level search with facet chips for kind, category, and tags and a sort control; an Installed tab lists the plugins this server has installed and their update availability. Selecting a listing opens its detail — the items it carries, its version history, its description, and homepage and repository links; when the plugin is installed, any security advisories affecting the installed version show there too. The detail drives install, update, and uninstall against the server’s /api/marketplace/* routes, with progress surfaced in place.

​

System

The System screen is the operational read-out: a health badge from the server’s liveness probe and a Metrics panel that renders the server’s raw Prometheus exposition. It is the fastest way to confirm a server is up and answering.

​

The scoped Studio

There is one Studio, not a separate portal per role. When you sign in with an owned key — a capability-scoped credential rather than a full-privilege one — the shell renders from that key’s capability projection (GET /api/auth/me): the sidebar trims to the features the key can reach, each list slices to what its scopes cover, and the data-bearing inboxes filter to the key’s own identity. Nothing is hidden by the client; the projection is the same derived, jq-exact view the request gate enforces, so the UI never shows a door the server would then deny. The screen below is the same Tools screen as above, but signed in as an owned key: the sidebar carries only Tools, Interactions, Notifications, and Settings — the operator surfaces (Dashboard, System, Marketplace, and the rest) are gone. This key’s projection reaches the tool surface, so its catalog is the full list; the scoping visible here is the trimmed navigation, and the genuinely sliced views are the identity-filtered inboxes below. A key whose scopes did not reach the tool surface would list fewer tools — or carry no Tools link at all. The Interactions and Notifications inboxes are isolated by identity. A restricted key sees only messages addressed to its own key identity by audience — the pending questions and notifications keyed on that key itself (its own island, not shared with sibling keys under the same owner), never another identity’s slice and never an operator’s broadcast. You hand an owned key to another device without exposing the secret by minting it from the API-keys tab and turning it into a one-time QR claim link in the create dialog. The owned-keys guide walks the full flow.

​

The rest of the sidebar

The remaining links follow the same shape — a master list on the left, a detail or editor on the right:

• Agents — the agents the manifest registered, each with a run entry.
• Presets — versioned tool-wraps and their version history.
• Extensions — the extension catalog and the combos attached to each tool.
• Interactions — the human-in-the-loop inbox of pending questions.
• Connectors — OAuth connections to outside apps.
• Hooks — event hooks wired to the server.
• Scheduling — scheduled tool runs.
• Manifest — the live manifest of mounted MCP servers and user tools.
• Settings — server configuration, environment values, and API keys (see Admin console and API keys).

Several of these surfaces are backed by Redis or Postgres in the running server; a screen whose store is not provisioned says so plainly instead of showing a fabricated state. See the Studio SDK reference for the components and hooks these screens are built from.