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.

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. 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 (such as email, drive, or a generic API) are being rolled out provider by provider, conservatively (read and draft before send; write behind approval). Until a provider's connector is live, a tool you select is configuration only and has no external side effect — the guard and audit trail are already in force, so nothing runs silently.