---
title: Tools
description: Where an agent's tools come from, and how they are named.
---

Every tool an agent can call comes from a **grant** in its version, or from a client of the session. Each source has its own prefix, so the model — and your code reading the log — can tell them apart: a tool reaches the model as `<kind>__<name>__<tool>`.

| Kind | Granted by | Example | Runs |
| --- | --- | --- | --- |
| `mcp` | An MCP server grant | `mcp__orders__lookup` | On the MCP server, with the session's vault credential for its URL |
| `skill` | A skill grant | `skill__refund-policy__read` | In Subako: reads the skill's files |
| `sandbox` | A sandbox grant | `sandbox__build__exec` | In the session's own Linux sandbox |
| `fn` | A function package grant | `fn__anydoc__convert_to_markdown` | In Subako, as a [function](/functions) call |
| `builtin` | Built-in grants | `builtin__ask_user__ask` | In Subako: forms, naming the session |
| `client` | A client of the session | `client__web__highlight_row` | In your app, as a [client tool](/build/client-tools) |

The `<name>` is the grant's name, chosen in the version: lowercase letters, digits, and `-`, up to 32 characters, unique among grants of its kind. `parent` is reserved.

## Policies

MCP servers, sandboxes, and functions run their tools under a policy — **Allow**, **Ask first**, or **Deny** — set per grant and overridden per tool by exact name. A denied tool is not offered to the model at all; one that asks first waits for an [approval](/build/approvals-and-forms). Skills, built-ins, and client tools have no policy: granting them is the decision.

## Credentials

A version never holds a credential. It names where a tool reaches — an MCP server's URL, a function's origins — and the session's [vaults](/console/vaults) hold what to present there. Subako attaches the credential to the outgoing call, so the model, the engine running it, and a function's module never see it.

This is what lets one published version serve many customers: the version says what the agent may do, and the session says whose credentials it does it with.

## Sandboxes and functions

A function runs code you wrote, in a fresh sandbox per call, with no network unless granted and credentials attached by Subako. A sandbox is a Linux machine of the session's own, running whatever commands the model writes. Prefer functions, and grant a sandbox only for programs that need Linux — see [Sandboxes](/sandboxes#start-with-a-function).