Admin console & live ops

The Studio is also the live operations console for a server. You confirm it is healthy, read its configuration, and drive live operations — reloading a tool, updating the manifest, or removing a capability — without a restart and without leaving the browser.

​

Health

The System screen reads the server’s liveness probe. A green Healthy badge confirms the server is up and answering. The demo instance below shows a populated Healthy badge.

​

The kinds table

The System screen also reads the server’s kinds summary — the plugin kinds the server knows about and, for each, whether it is active (a provider is configured and running), running on a default (the built-in fallback is in use), or off (the kind is not configured). It is the fastest way to confirm which providers a running server actually resolved — for example, which identity and accounts providers the configured auth-provider chain brought up, or whether file loading is installed (the files row). The same summary is served at GET /api/system/kinds and printed in the server’s startup log — see live operations.

​

Members

Administration › Members is the Studio-core surface for a server’s human accounts. It lists people and pending invitations aggregated across every configured accounts provider — read through the accounts-provider contract, so a provider needs no bespoke Studio page to appear here. Each row carries an opaque routing handle back to the provider that owns it. The page performs each provider’s own declared member actions — invite a person, change a role or access, remove a member, send a login link, cancel an invitation — through a single generic invoke door. The page renders header buttons and each row’s action buttons from the provider’s action declarations and reads no field of any action’s input or result; a provider adds or changes an action by changing its declaration alone. The role picker reflects the current editable role set: the seeded admin/editor/viewer plus any role an admin has created with tai roles. The page governs only the usr-* human principals. Machine keys are managed on the API keys surface, and a principal provisioned directly through the raw access-control policy routes is governed there — see the principal-type split. The page has two cards. People lists each member’s email, role, status and creation date, and Pending invitations lists each invitation with when it was sent and when it expires; in both, a Provider column shows the display name of the provider that owns the row, and an Actions column appears where a row has actions. A member’s role reads No role when that member’s access was set directly rather than from a role, and Mixed roles when the person’s logins hold different roles; the badge lists each login’s role with “Give every login of this person the same role.” The status reads Active, Disabled or Partially disabled. With no people and no invitations the page reads “No members yet”; otherwise an empty card says “No people have been added yet.” or “Outstanding invitations appear here until they are accepted or expire.” Each page-level action button carries a badge with the name of the provider that performs it — the display name that provider declares — and its dialog names that provider too. An action opens a dialog titled with its label: a form drawn from the action’s declared input, or “Run this action now?” for an action that takes none. A destructive action asks once more (“This is a destructive action. Confirm to proceed.”) and runs on Confirm. A result that carries a secret shown only once says “Shown once — copy it now; it cannot be retrieved again.”

​

The operations dashboard

The Dashboard summarises the server’s monitoring backend — total runs, cost, latency, and token counts over a time range, with a per-model breakdown and a trend chart. It answers “what has this server been doing” at a glance. The demo instance below is populated from a monitoring backend seeded with example runs, so the summary tiles, trend chart, and per-model breakdown show representative data. With no monitoring backend registered, the Dashboard renders a clean empty state instead. The per-model breakdown distinguishes three cases: it shows the bars when per-model data is available, a plain empty state when the range holds no per-model activity, and a distinct “Per-model breakdown is unavailable for this range.” notice when the per-model figures could not be computed — so an unavailable breakdown is never mistaken for an idle one.

​

Settings and environment

The Settings and Environment tabs are the deployment’s admin-owned config store: the server’s configuration mode, its settings schema, and the stored environment values — one store holding the stored environment plus each settings class’s values, including deployment secrets such as the connector encryption key. Each subsystem’s settings — connector crypto, engine config, store connections — surface as an editable form. Because that store is admin-owned, both tabs are admin-only; an editor or viewer configures each feature through the feature’s own screen, never here — see user types and permissions. A setting that the environment of any server or backend process of the deployment sets belongs to the deployment for every process on the same worker bus, and its value wins over a stored one. Studio shows it locked, marked Set by the deployment: on the Settings tab the field shows read-only the value of the worker that answered (a worker whose own environment lacks the setting runs, and shows, its fallback or default), and on the Environment tab a stored row for that key cannot be edited and keeps only its Remove, with the note Stored value not used; the deployment’s value applies. The lock follows the key a row was loaded with: a row added in the editor is never locked, whatever name it is given. Re-adding a deployment key whose stored row was removed and saved gives such an unlocked row, and saving it with a value is refused with a 400 that names the key. To change such a value, change the deployment’s environment and restart. A profile save, a profile apply, or a backup restore that sets such a key to a new value is refused, naming the key; the profile diff lists it among the refused keys. See deployment values and stored values. Saving the Environment tab writes the stored environment and reloads the fleet. A change to a recycle-class setting — one whose pooled resource is built only when a worker process starts — also rolls a worker recycle, and the tab shows it under Worker recycle: one row per worker the roll reached, a recycled worker joined onto its fresh life, and the worker that took the save recycling itself after replying. A roll that stops says where and why, and the workers the server names as still awaiting a respawn are listed as waiting for a restart; the Apply profile report shows the same rows and the same list. A worker the stored configuration did not build on is listed apart and told to fix the stored configuration first, since a restart would not help it. See reload classes. Every other change whose reply can carry a roll shows the same report: the Settings tab save, the MCP config save and secret paste, manifest sections, tool extensions, tool picks, Reload config, a listing installed in a connector’s Connect step, and the marketplace’s install, update, uninstall and Upgrade all. A worker the roll restarted, deferred or confirmed clean is not listed as failed. A write that fails after running a roll shows that roll beside its error, in a dialog too. The Worker recycle heading and the heading of each worker panel end with the write they report, on every screen: Worker recycle — environment on this tab, Worker recycle — apply profile in the Apply profile report, and Worker recycle — env for a restored env section. An MCP save that lands several writes names each one on its own report. An export on the Backup tab downloads the file even when a section fails to export. A warning under the export controls then names each section left out of the file, with its message. Restoring a backup’s env section on the Backup tab is the same env write. Its import report lists the workers the server names as still awaiting a respawn, and shows the section’s Worker recycle rows when the restore rolled a recycle, with where and why a stopped roll stopped. A restore that sets a key the deployment’s environment sets is refused on the section’s row, naming the key, and nothing is stored. Export and import on the Backup tab are admin actions. A role that may read backups sees the tab and its sections, and in place of each action a line saying so: “Exporting a backup is an admin action.” and “Importing a backup is an admin action.” The API keys tab on this screen is separate and self-service: every signed-in user sees its own keys there. A user whose access permits minting keys creates, edits and revokes them, on a read-only deployment too; any other user reads “Your access does not permit minting keys.” in place of the Create key button. A key’s policy History, and its rollback, show to admins only. A key needs a description and at least one scope, Full access, or a condition: the create and edit dialogs refuse a key without them before anything is sent, keep the form open, and say what is missing — “A description is required.” or “Choose at least one scope or Full access, or set a condition under Policy. A key with none of them grants nothing.” Where the Full access box is not offered, the refusal reads “Choose at least one scope, or set a condition under Policy. A key with neither grants nothing.” The create dialog also refuses an empty Key user ID with “Key user ID is required.” Below the keys, the same tab carries the Access control card: the scopes mapper that decides which scope covers which route. Each scope is a zone listing the routes mapped to it, with a row to add a route or a dynamic pattern by hand. Unassigned holds every route and sub-MCP mount no scope covers yet, apart from the routes pinned public and the routes public by their own declaration (both below). The Public zone, marked no auth, holds the routes pinned public: they are served without API-key authentication or any scope check, so it is not a scope. Drag a route onto a scope to map it, or onto the Public zone to pin it public after a confirm step; the drag works from the keyboard as well. The routes public by their own declaration are listed apart, under Public by declaration, as plain chips you cannot drag: they are served without API-key authentication whatever scope or pin they are given, so they are never Unassigned and the server refuses to map them. The card shows only to a caller whose access reaches the route, public-route and sub-MCP reads it is built from, which an admin always does.

​

Live operations

Because the Studio drives the same /api/* surface as the tai CLI, the management operations are one run away. From the Tools screen you invoke reload_tool, remove_tool, or reload_config — the live operations — to reload a tool, drop one from the live registry, or soft-restart the server in place. While a reload is in flight, the API answers dispatch routes with a retriable 503 rather than serving against a half-swapped registry. See live operations for the management operations, and the CLI reference and HTTP API reference for the routes behind each screen.