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 and scope tiers, 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.

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 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 connector when a signed host/method/path allowlist and credential exist, and slack.post_message for a bound Slack channel. Other provider entries remain configuration-only until their connector ships, so nothing runs silently.