Reference

Tools

The tool registry is the single place to see every capability your agents can be granted (what each one does, whether it causes side effects, how risky it is) and to switch any tool off across your whole organisation.

What the registry is for

A tool is a capability an agent can use: sending a message, creating a record, querying a system. Tools are built into the platform as code, not authored from the registry. The catalogue is the governance and metadata layer over that code. It tells you, for each tool, exactly what it can do and how it behaves before you ever let an agent near it.

Every tool you can see falls into one of two groups: platform tools, which are available to all organisations, and any tools provisioned specifically for your organisation. The registry lists both together, grouped by category.

The registry is reached at Tools in the sidebar, between Agents and Runs. The whole page is a governance surface, so it is restricted to organisation owners and admins (the tools.manage permission). Operators do not manage tools here. They meet tools through the agent version editor's picker when they build an agent.

Reading a tool entry

Tools are grouped into collapsible categories (Communication, CRM, and so on); categories start collapsed because the list is long, and any active search or filter automatically opens the groups that contain matches. Each tool row shows:

• Name and slug: the human label plus the stable identifier (for example send_email) used in agent assignments and the audit log.
• Risk level: one of low, medium or high, shown as a badge to signal how much scrutiny a tool warrants.
• Side effect: a badge present when the tool changes something in the outside world (sends, writes, deletes) rather than only reading. Side-effecting calls are the ones that pass through the approval gate.
• Integration provider: shown when the tool talks to a specific external service.
• Schema: expand Schema on any row to view the tool's input schema as JSON, so you know exactly what inputs it accepts.

To find a tool quickly, search by name, slug or description, or narrow the list with the category and risk filters at the top. Use Clear filters to return to the full catalogue.

Enabling and disabling tools

Each tool has two switches that combine to decide whether it can be used in your organisation:

• The platform switch, controlled by the SyftOS team. When a tool is switched off platform-wide it carries a Platform disabled badge and reads "Switched off platform-wide". You cannot turn it back on from here.
• Your organisation switch, controlled by you. Use the Enable / Disable button on each row to turn a tool on or off for your whole organisation, without touching any individual agent. A tool you have disabled shows a Disabled for organisation badge.

A tool is only usable when both switches are on. Disabling a tool here is the fastest way to remove a capability everywhere at once.

How it ties into governance

The registry is where capability meets control. Two properties shown on every row drive what happens at run time:

• Side effect determines the approval gate. A side-effecting tool call becomes an action that waits for a human decision before it executes — agents never carry out side effects autonomously. Read-only tools generally do not need that gate.
• Risk level helps you judge which tools to grant, which to keep disabled, and where to focus review.

Every change you make here is governed too: enabling or disabling a tool is audited, and so is every blocked attempt to use a disabled tool. Because managing the registry sits behind tools.manage, only owners and admins can change what the organisation can do — the same boundary that protects the rest of your control plane.

Things to watch

• Tools are never deleted; one that is no longer offered is retired by being switched off, so historical actions and audit records keep resolving forever.
• Re-enabling a platform-disabled tool is not possible from the registry; that switch belongs to the platform.
• Disabling a tool does not warn the agents that depend on it. If a tool is mid-workflow for several agents, expect their next attempt to fail safely until you turn it back on.

Next steps