Available tools guide

ROST tools are capabilities that a seat can use when its Charter allows them. Tool availability depends on the tenant, integrations, credentials, and the seat's permission manifest.

Tool categories

• Context tools: read company context, Charters, goals, and recent events.
• Reporting tools: report Status, Handoffs, Friction, and escalations.
• Operating tools: create tasks, update issues, record Signal readings, and prepare Sync inputs.
• Integration tools: work with connected systems such as finance, communication, support, or local runner surfaces.
• Local tools: MCP and CLI access used by a human-controlled local agent session.

How to choose tools

Start from the seat's responsibility, not the tool list. If a tool does not directly support a responsibility or measurable, do not connect it yet.

Skills and tool dependencies

Skills are reusable procedures a seat can learn from; they are not tools and they never grant authority. A skill package may declare required or optional tool dependencies so setup can identify blockers before assignment. Those dependencies are checked against the discoverable tool.catalog ids, scope tiers, and provider-neutral access levels, then compared to the seat's Charter permission manifest. Missing required tools block approval; optional tools produce setup warnings. A published skill version is immutable, so later corrections create a new version instead of rewriting what a run may have used.

The catalog covers both the platform verbs (status, escalation, Signal readings) and the business tools the stock-agent templates grant — accounts-payable and receivable reads, AP-inbox and collections drafts, helpdesk triage, CRM reads, web search, public-page fetch, browser read, working files, script execution, content-calendar, release-artifact, and issue drafts. Each is listed with a conservative scope tier (read for the reads, draft for the drafts and action-capable internal workbench tools), a provider-neutral access level, a provider requirement, cost class, lane support, and any Trusted-mode metadata that must be present before a standing authorization can apply. Business tools are credential-gated unless they are ROST-managed generic workbench tools. Because a skill's required tool id is matched against these ids, a skill that requires one of them resolves against the catalog rather than reporting an unknown tool. Catalog membership is configuration only: it still confers no authority, and a listed id runs only once a live handler exists behind the seat's signed permission manifest, the server guard, and any required credential — the manifest and guard remain the control plane. Unknown tool ids or unsupported access levels fail closed.

How agents should request tools

Agents should explain the job, the required tool category, the minimum permission needed, and the escalation boundary. Humans approve or decline the request.

How a tool actually runs

Every tool call passes the server-side guard first: the guard checks the call against the seat's signed permission manifest and records a tool-call audit row for every call — allowed, denied, or escalated. Tool selection is never authorization. An explicitly declined manifest entry is enforced as denied, even when the tool exists and the client asks for it. Only an allowed call reaches its handler. A connected credential is bound into the handler for the duration of the call only; the secret never appears in the result, the audit summary, logs, or the model's context.

External connectors are being rolled out provider by provider, conservatively (read and draft before send; write behind approval). A selected tool is only a permission until a live handler exists and the seat has the required credential or binding. Today the built-in execution path supports internal status reporting, the generic REST GET connector when a signed host/path allowlist and credential exist, slack.post_message for a bound Slack channel, Google handlers for gmail.read, gmail.draft, sheets.read, and approval-held sheets.write when Google is connected, plus the governed workbench tools web.search, web.fetch, browser.read, files.read, files.write, and script.run. web.search uses a server-side Exa provider and returns normalized cited results without exposing provider keys. web.fetch reads one public HTTPS page only after scheme, DNS/IP, redirect, content-type, size, and timeout checks pass. browser.read opens an ephemeral read-only public-network browser session for navigation, inspection, screenshot, or extraction; it does not submit forms, persist authenticated state, execute downloads, or expose cross-tenant artifacts. files.read and files.write operate on bounded tenant-scoped working files and published rost://working-files/<id> references; they reject traversal, cap text payloads, retain ephemeral files briefly, and never execute file contents. script.run is compute-only and network-denied by default, but arbitrary code execution is action-capable, so read-only posture does not grant it; it still requires the agent.script_run entitlement and returns size-capped output. gmail.send remains held for approval and live external send stays gated on Google verification. Before that verification is complete, partner demos should show sandbox dry runs, setup previews, and approval-held examples rather than claim production Google readiness. Other provider entries remain configuration-only until their connector ships, so nothing runs silently.