Scenario Team Admin

Scenario Team Administration

Overview

Enterprise teams govern Scenario from the same agent that generates on it: which models anyone may run, who is on the team and in which projects, how much each member may spend, and which API keys exist with which roles. Every tool here is catalog-only: scenario_tools_search returns the schema and lane, and scenario_tool_execute_read / write / delete runs it with {name, parameters}, scope ids inside parameters (see the scenario skill). Two facts decide most failures before any argument does: the identity behind the call, since team-level writes need a human team admin over OAuth and refuse API keys, and the list mode the team runs, since the same model-access edit means the opposite thing in blocklist and allowlist mode. teams_list already tells you both: each team row carries modelsManagement, its model lists, plan, and context.userRole. A credential that reaches one team and one project has its scope; more than one is a stop-and-list, per the scenario skill. If a sibling skill named here is missing from your available skills, ask the user to install it (npx skills add scenario-labs/skills --skill <name>); unattended, proceed from tool schemas and flag the gap.

Quick reference

Model access: read the mode before editing

model_access_get returns models_management and only the mode's active list; the inactive stored list is never surfaced. In blocklist mode (the default) every catalog model is available except those on the team or project blocklist, and the two lists block as a union. In allowlist mode a model is available only when it sits on both the team and the project allowlist; a project with an empty allowlist denies every model, and a project with no allowlist configured falls back to the team list.

model_access_update edits whichever list the mode makes active, so add_models blocks in blocklist mode and allows in allowlist mode: read the mode first, every time. Switching the mode is not available through MCP; it lives in the web app's team settings, so locking a team down to an approved set starts with the user flipping to allowlist there. Unattended, that switch is a stop-and-report: log that the lock waits on it and the exact calls that follow, and take the blocklist-safe partial (blocking the named unwanted models at project level), saying that other projects stay open. Narrowing a list the credential can edit is in scope when the task states the target set: remove_models runs after the adds succeed, so the list never ends empty. level: "team" needs a team admin over OAuth, and the server refuses API keys on that endpoint. level: "project" takes the projects to edit in projects (1 to 200) and needs the admin role on every one of them: one unauthorized project fails the whole request and nothing updates, and a single-project key can only edit its own project's list. project_id on the call is tenant context for OAuth sessions, never the target. In allowlist mode a project admin can add only models already on the team allowlist (a project list narrows the catalog, never widens it), removing a base model from a team allowlist cascade-removes the trained models built on it, and a team-level add validates every id, one unknown id failing the whole call. updated: false means the diff was a no-op, not an error. A blocked model disappears from what members can run, and the error a member sees when running one anyway is a restriction, not moderation (see scenario-moderation).

Members and spend caps

team_members_update takes member_ids from team_members_list and sets role (admin or member), max_consumption, or both. The cap is in Creative Units over the current billing period: a value of zero or more caps, -1 is unlimited, and null clears the per-member override so the team-wide default applies. Roles can be set by a team admin over OAuth or a team-scoped API key with the team.members.manage scope; caps need a real team admin, and a key that tries is refused per member. Demoting the last admin fails server-side. The bulk member tools process one row at a time and report an outcome per member; a response with status: "partial" is finished by calling again with its remaining list.

team_members_add invites 1 to 32 emails at role (default member) and joins them to project_ids on acceptance; outcomes are invited, failed, or skipped with the reason (already a member, already invited, seat limit reached). project_id on the call grants nothing. Like role changes, inviting takes a team admin over OAuth or a team-scoped key with team.members.manage; a project-scoped key gets a permission error. A pending invitation carries no member id, so its cap waits for acceptance. project_members_add takes people already on the team, as user ids or emails (emails need team_id to resolve), with a required project role.

Removal is the delete lane and immediate: team_members_remove ends the person's access everywhere and withdraws pending invitations, project_members_remove leaves team membership and other projects untouched. List first, confirm the exact names with the user, then remove; unattended, remove only the members the task instructions name.