Skip to content
AlumiaDocs

Search docs

Find pages, headings, and concepts. Press ⌘K or Ctrl+K to toggle.

Tool calling

Give an agent built-in tools and connector-backed tools, and scope what it can do.

Open in ChatGPTOpen in Claude

Tools are what let an agent do work outside plain text. Built-in tools ship with the platform; connector-backed tools come from external services you've authorised. Both categories show up in the same place on the agent edit page.

1. Open the agent

Go to /<orgSlug>/agents and open the agent you want to extend. Find the Tools section. The list groups tools by category — search, files, browser, sandbox, canvas, memories, peer messaging, email, contacts, telephony, datasets, learning, and connector-backed groups.

2. Enable built-in tools

Built-in tools are toggleable per agent. The ones you'll reach for most:

  • Web search — query the web and return ranked results.
  • Browser session — open a real browser via Browserbase, navigate, click, and read the rendered DOM.
  • Sandbox — spin up a sandboxed Linux environment to run shell commands and code.
  • Files — read and write files in the project's storage.
  • Canvas blocks — generate documents, code, tables, charts, images, and other block types directly onto the canvas.
  • Peer messaging — spawn_agent, message_agent, check_messages, list_agents, create_agent.
  • Memories — write to and recall from the project's pgvector memory.

Toggle on what the agent needs. Toggle off what it doesn't. A focused tool set produces shorter prompts, fewer wrong tool picks, and lower cost.

3. Add connector-backed tools

Connector-backed tools come from /<orgSlug>/connectors. Browse the catalog (541 connector slugs across productivity, communication, developer, billing, commerce, cloud, and data services), find what you need, and click Connect. Most use OAuth and open the provider's consent screen in a normal new tab. After consent, the tab returns and the connector appears in the Connected list.

Back in the agent's Tools section, the connector now exposes its operations as callable tools. For example, after connecting Gmail you'll see gmail.list_messages, gmail.search, gmail.send, and so on. Enable only the operations the agent should use.

4. Scope narrowly

Tool access composes across four layers:

  1. Org — the connector must be connected at the org level.
  2. Project — some tools (memories, canvas blocks, files) are project-scoped automatically.
  3. Agent — the tool must be enabled on this agent.
  4. Provider config — connector OAuth scopes limit what the connector can actually do, regardless of which operations you enabled.

If the agent only needs to read a calendar, do not give it write. If it only needs gmail.search, do not enable gmail.send. Narrow scopes contain mistakes.

5. Verify in the lab

Open /<orgSlug>/lab, pick the agent in the prompt bar, and ask it to do something that requires a tool you just enabled. Watch the tool call land on the canvas — the call's name, arguments, and result are visible per-step. If the call is missing or returns an auth error, see Troubleshooting.