Tool broker

The tool broker is the part of the platform that exposes tools to agents within controlled boundaries. Rather than giving an agent unrestricted access to your machine and network, the broker mediates a defined set of tool categories and enforces the limits your organization sets.

Every agent run — desktop, CLI, or cloud — interacts with the world only through tools the broker registers. There is no parallel unmediated path for MCP or plugins.

How mediation works

1. Register

   At session start, the broker loads built-in tools plus MCP servers from installed plugins and user configuration.

2. Invoke

   When the model chooses a tool, the broker validates arguments, applies path and scope rules, and checks whether approval is required.

3. Execute

   Approved calls run in the appropriate sandbox — local workspace or cloud environment — and results return to the agent.

4. Audit

   Tool use is observable for review, especially important for delegated and cloud agent work.

Tool categories

The broker exposes these categories of tools to agents:

See Tools for a member-facing guide to each category.

Controlled boundaries

Tool access is bounded, not open-ended:

Organization policy — including model control and governance — constrains what runs and how.

Approvals through the broker

The broker implements a consistent approval model across categories:

Agent requests tool call
        ↓
Broker evaluates: path rules, command heuristics, org policy
        ↓
Needs approval? ──no──→ Execute
        │
       yes
        ↓
User approves / denies / allows for session
        ↓
Execute or cancel

Members control approvals at runtime. Admins control what tools and integrations are available at all — see Agent security.

Governance for admins

1. Model catalog

   Restrict which models agents can use via Model control.

2. Budgets

   Cap token spend with budget policies so agent loops cannot run unbounded.

3. Plugin curation

   Decide which marketplace plugins members may install — each adds MCP tools through the broker.

4. Cloud network

   Define egress allowlists for cloud agents so MCP and web_fetch cannot reach arbitrary hosts.

Implementation in the monorepo

Built-in tools are defined in packages/agents-core and wired through the AI SDK ToolLoopAgent — there is no alternate execution path for repository or terminal tools. Cloud runs in apps/agents-api reuse that core set and extend it with org-scoped analytics and canvas tools from createCloudAgentTools. Desktop and CLI sessions pass a local sandbox context; cloud workers pass an isolated Vercel sandbox with the same tool names so prompts and skills behave identically across surfaces. MCP and plugin tools register at session start alongside these built-ins.

Desktop vs. cloud

Both surfaces use the same broker architecture; the sandbox differs: