Tools

A tool is a single verb the model can call in the middle of a run. The executor assembles a fresh tool registry for every run from what the agent declares and how it is configured — nothing outside that registry is callable.

Three sources of tools

How a tool gets enabled

Some tools you list explicitly; others switch on automatically because of how the agent is configured. The Tools page in the app shows this per tool.

The built-in catalog

Browse the live list in the app under Tools → Built-in; each card has an info popup with usage and copy-ready Agent and Skill examples. The catalog is derived from the same registry the executor uses, so it can never drift from what actually runs.

Web

• web_search — search the web and return result snippets. Uses the provider configured under Admin → Web Search (Serper or Tavily), resolved per org with a platform fallback. An agent can ask for a fast search (the default) or a thorough one for niche or recent topics; Tavily searches deeper, Serper has one depth.
• web_fetch — fetch a URL and read it. A web page comes back as its main text, without navigation or boilerplate, headed by its title, publication date and source. A PDF comes back as its text, marked page by page, and as a file for later use. Long documents are read in sections: each reply says where it stopped and how to continue. Pairs with web_search.
• browser_use — drive a headless browser under governance: navigate/extract are reads; click/type/submit/download are writes that route through the approval gate. Reachable domains are default-deny via the browser-egress policy, and extracted text is DLP-screened.

Compute & media

• code_execution — run a Python or Node script in an isolated, network-less sandbox that exists for that run alone. Files written to the output directory come back as downloadable artifacts, rendered inline in chat. Use for charts, data analysis, PDFs, and image processing.
• generate_image — text-to-image; returns an inline image artifact.
• qr_code — turn a URL or short text into a scannable QR image.

Everyday utilities

• current_time — the current date/time in any IANA timezone. Use instead of guessing today's date.
• calculate — a safe expression evaluator (arithmetic plus sqrt, log, round, min/max, factorial…). Avoids in-model arithmetic mistakes.
• convert_units — length, mass, temperature, time, data size, speed, volume, area.
• get_weather — current conditions for a place.
• currency_convert — convert between currencies at reference rates.
• market_data — end-of-day price history for stocks, indices, FX and crypto, registered as a dataset that render_chart can reference by name.

Knowledge, memory & skills

• search_knowledge — retrieve chunks from attached collections with citation ids. Returns an explicit "not in knowledge" result when nothing matches, so the agent doesn't invent an answer.
• remember / recall — durable user or agent facts, deduplicated on write and auto-injected into later turns.
• load_skill — progressive disclosure: index, then body, then a specific reference file on demand.
• run_skill_script — run a skill's declared entrypoint in the sandbox.

Interaction & orchestration

• ask_user — pause the run and ask a clarifying question; the reply becomes the tool result.
• write_canvas — create or update a shared living document; the user's edits are shown to the agent next turn.
• render_ui — show an interactive surface (a form, a choice, an upload) and wait for the answer.
• render_chart — draw an interactive chart from a full ECharts option; the run does not pause.
• schedule_followup — schedule a one-shot future wake-up, bounded by org policy caps.
• map_over — fan a task out over a list, one child run per item, with count and cost caps and isolated failures.
• propose_skill — propose a new skill into the review workshop (creates a proposal, never a live skill).

Authoring (the Architect toolset)

Declarable, and only meaningful on an authoring agent such as the built-in Architect. Drafts are conversation-scoped — nothing here writes to the registry.

• read_definition — read an existing agent definition you can see.
• write_definition — write a draft into the conversation's buffer.
• validate_definition — validate a draft through the same pipeline the editor uses.
• search_catalog — search visible agents and skills for prior art.

Governance around every tool call

Each of these is a policy with a documented configuration and default — this is the summary of how they land on a tool call.

• Allowlist — a tool-allowlist policy can deny a tool org-wide or per team/agent. Deny wins, and a denied MCP server is hidden entirely rather than failing loudly.
• Writes park — tools tagged as writes go through the approval gate under the agent's effective autonomy.
• DLP — sensitive patterns are redacted from input before the model sees it and from output before delivery, including tool results.
• Injection screening — content coming back from the outside world (tool results, knowledge) can be screened before it re-enters the model.
• Audit and cost — every call is recorded on the run's event stream, and token/cost usage is written to the ledger.

MCP servers: sign-in and tool rules

A registered MCP server (Catalog → Tools → MCP servers) connects over sse or streamable-http and chooses how it signs in:

• None — an open server.
• Server key — one secret from Secrets, sent as a bearer token when the platform discovers the server's tools and on every call.
• Each person, with their own account — for servers that act as a specific user (Microsoft Work IQ, most SaaS servers). The administrator registers the server with the OAuth app's client id; the endpoints are discovered from the server. Each person then presses Connect once. Calls carry the token of whoever started the run, never a shared one. Someone who has not connected sees a Connect card in chat; over the gateway the call is refused.

Generic tools that act on a resource path — fetch, do_action — say little in their names, so two more controls apply:

• Classify tools — the server's registrant or an org admin marks each tool read, write, destructive or disabled. A disabled tool is never offered to a model or a gateway client; write and destructive tools go through the approval gate.
• MCP tool rules — a policy (mcp_tool_rules) matching server, tool and the call's resource path: allow, approve (park for approval even under trusted autonomy) or deny. The strictest matching rule wins, so a narrower scope can only tighten. Example: approve do_action /me/sendMail*, deny /admin/*. Agents and gateway clients get the same answer.

Declaring tools

Agent.md

---
name: research-assistant
model: default
tools:
  - web_search
  - web_fetch
  - code_execution
  - current_time
---

SKILL.md — a skill may only use tools the agent already grants

---
name: weekly-report
allowed_tools:
  - web_search
  - code_execution
entrypoints:
  build: scripts/build_report.py
---