Use built-in tools

Built-in tool sets are registered by the AXL server, so they need no external process and no extra credentials beyond whatever the underlying service requires.

Two names, two places

A tool set is what the server registers and initializes; granting one gives the agent every tool in it. A tool is the thing the model actually calls. Put a set name where a tool name belongs and it silently matches nothing.

Print the real list

The catalog is a property of your running server - which sets were compiled in, which are configured - so ask it rather than trusting a list in a document:

axl tools list                 # every registered set and the tools it provides
axl tools list --set memory    # just one
axl -o json tools list         # machine-readable

+----------+-------------+------+--------------------------------------------+
| Tool set | Tool        | Op   | Description                                |
+============================================================================+
| web      | web_crawl   | read | Crawl a website starting from a root URL,… |
|          | web_extract | read | Extract the full content of web pages.     |
|          | web_search  | read | Search the web for current information.    |
+----------+-------------+------+--------------------------------------------+

GET /api/v1/tools returns the same thing. Because it is built the way a workflow tool node builds its context, a name listed there is a name that node can call.

A set can list no tools. That means it contributes nothing in a neutral context: either it builds its tools from per-agent state (memory needs that agent's memory store) or it is not configured on this server (web is empty without TAVILY_API_KEY). Which of the two is inside the set's own code, so the listing does not guess.

For what one agent actually ended up with - after its toolsets, its credentials, and its [tool_loading] budget - ask about the agent instead:

axl -o json agents info <agent-key>

That is the only view that reflects a real run, including which tools were deferred behind tool_search and which stayed pinned.

The sets

Names are deployment-dependent. A tool set must be registered by the server as well as listed on the agent, so this table describes what AXL can offer rather than what your particular server does. Start with the smallest set, and test the exact action through the agent before granting more.

blob is scratch space, not storage: blobs live in Redis and expire with the session. For files a person keeps, see Files.

web_search's country filter takes a full country name ("germany", not "de"); the common two-letter codes are accepted and normalized.

A set must be registered by the server and listed on the agent. code_agent is not a set of its own: it arrives through sandbox-local or sandbox-remote when its coding-agent credential and safety settings permit it. Prefer the remote sandbox for autonomous repository work - local execution reaches the host and needs an explicit operator opt-in.

Tools from MCP servers

An MCP server's tools are namespaced by the server they came from:

mcp__{server}__{tool}      e.g. mcp__snowflake__run_query

The prefix is what keeps two servers that both expose search from colliding. Those names are not in the table above because they depend on which servers you connected; axl agents info prints the resolved ones. An autonomy glob is the practical way to gate a whole server:

[autonomy]
"mcp__snowflake__*" = "require_approval"

See MCP for connecting servers.

Granting less than a whole set

A bare name grants everything the set provides, which is usually what you want. When it is not - toolsets = ["microsoft"] hands over microsoft_send_mail along with the calendar - narrow that one entry in place:

toolsets = [
  "memory",
  { name = "microsoft", except = ["microsoft_send_mail"] },
]

only is the other direction, for when the short list is the allowed one:

toolsets = [
  { name = "microsoft", only = ["microsoft_list_events", "microsoft_read_recent_mail"] },
]

Use one or the other; setting both fails the boot. A dropped tool is not merely blocked - it never reaches the agent, so it costs no context window either. Naming a tool the set does not provide narrows nothing and logs a warning, since the set's output depends on configuration and a name that matches nothing may be a typo or simply absent from this deployment.

Narrowing decides what the agent holds; [autonomy] decides what it may do with what it holds. Reach for autonomy when the tool should exist but need permission:

[autonomy]
"microsoft_*" = "require_approval"

The ones that carry real authority

Three entries in that table need extra care before you hand them to an agent.

web reaches the network. It has SSRF protection - private IP ranges and cloud metadata endpoints are blocked - but it is still an outbound channel.

The sandbox tools run commands. sandbox-local executes on the host beneath LOCAL_SANDBOX_ROOT; it is convenient for development and it is not an isolation boundary. sandbox-remote sends the work to a separate worker and is the right choice for anything autonomous. See Choose a sandbox.

code_agent is supplied through the local or remote sandbox tool set and appears only when its coding-agent credential and safety settings permit it. Prefer the remote sandbox for autonomous repository work - local execution reaches the host and requires an explicit operator opt-in.

Next

• Choose a sandbox - local versus remote, and what each one protects.
• Connect an MCP server - tools beyond what ships in the box.
• Middleware - caps and approval gates on tool calls.
• Tool reference - exact tool inputs and settings.