Toolsets

Toolsets are the calling layer over tools: what agents can call, who adopted what, and what fires in practice. The surface is /ai/agents/toolsets: Tools and toolsets agents can call.

• The agents column is adoption truth: which agents call this tool.
• Last called plus 30-day calls is usage truth. A tool with agents but zero calls is adopted, not used; a tool with no agents is shipped, not adopted. Both gaps are cleanup or enablement work, not mysteries.
• Filter by source, status, no-agents, or never-called to find the gaps. Add tool creates beyond the shipped set.
• Every tool is a capability and a liability. Tools often reach external systems through connector bindings and MCP installs; the tool is only real for the tenant when that chain is verified in-environment.

• The environment tool list is the source of truth. If a system is not listed there, sessions cannot reach it no matter what the registry or catalog suggests.
• Atomic layer and binding rules: Tool registry, Extend a connector. The shipped inventory: Catalog. Treat /ai/agents/toolsets as the source of truth for toolset surfaces.

Tool Policy: the resolved grants behind the Tools tab

What the agent may call in a session is the resolved Tool Policy — not the plugin manifest alone, and not the Tools tab alone. At session scope the installs, grants, and explicit Tools-tab rules resolve into one effective set, and the session panel shows that resolved set. See Plugins in session for the install → grant → session → invoke flow.

• Explicit Tools-tab Allow / deny rules participate in the resolution. A deny on a tool keeps it out of the session even where a plugin manifest marks the tool always-on — the manifest does not override an explicit deny.
• spawn_subagent is governed the same way: the Tools tab can allow or deny it per agent, and the resolved policy is what the session enforces. Treat subagent spawn as a capability grant, not a prompt detail. Scoped helpers live under Subagents.
• When a tool is missing from the session panel, read the resolution backwards: explicit deny? → granted to this agent? → installed for this tenant? → allowed by the environment policy? The break is usually one of those four, not a wording problem.

Records tools and the Add-tool path

Record-backed tools (create, read, update over tenant objects) resolve like any other tool: registry definition, agent grant, Tool Policy, environment scope. Where the product offers an Add-tool path to expose a record action as a callable tool, the added tool enters the same resolution — it is callable in a session only once granted to the agent and allowed by policy, not at creation time.

• Object configuration behind these tools lives under Objects with tenant fields under Custom Fields.
• Treat the product UI as the source of truth for which objects and actions the Add-tool path supports. Combinations this page does not name are not promised.