Skills and tools
How skills package instructions and tools, what built-in tools every agent has, and how the agent chooses what to use.
Tools are the individual actions an agent can take — make an HTTP request, search the web, read a file. Skills are the layer above: a skill packages instructions, one or more tools, and optionally executable scripts into a reusable capability you attach to an agent.
What a skill is
A skill bundles three things:
- Instructions — a description of what the skill does, when it should fire, and how the agent should carry out the task (steps, output format, safety constraints).
- Tool definitions — the named actions the skill exposes, each with a description of its inputs and outputs.
- Optional scripts — executable code that backs the skill's tools. Script-backed tools become real, directly callable tools; skills without scripts contribute their full instructions to the agent's system prompt instead, guiding how the agent uses the tools it already has.
A skill also declares its requirements — the external hosts it needs to reach and the credentials it needs — so the platform can wire up egress permissions and secrets automatically when you attach the skill to an agent. You pick skills from the platform's skill catalog or create your own in the console; see Agents for the authoring flow.
Built-in tools
Every deployed agent ships with a core set of tools, independent of which skills you attach. The most important ones:
| Tool | Purpose |
|---|---|
http_request | Call external HTTP APIs (subject to egress control) |
web_search | Search the web for recent information |
web_fetch | Fetch a web page and read its content as clean text |
json_parse, csv_parse | Parse structured data |
math_calculate, datetime_now, uuid_generate | Small utility operations |
file_read, file_write, file_edit | Work with files in the agent's own working directory |
file_create | Produce a downloadable file and deliver it to the user's channel |
read_skill | Load the full instructions of an attached skill on demand |
schedule_set, schedule_list, schedule_delete | Manage the agent's own recurring schedules |
memory_search, memory_get | Recall long-term memory (when enabled) |
File tools are confined to the agent's working directory — path traversal outside it is rejected — and every network-touching tool goes through the agent's egress allowlist.
Custom and integration tools
Beyond the built-ins, an agent's tool set can grow in three ways:
- Skill tools — each script-backed tool a skill defines is registered as a first-class tool under its own name, alongside the built-ins.
- Integration adapters — webhook and OpenAPI adapters turn external service endpoints into callable tools, and connected MCP servers contribute their tools automatically under a per-server namespace.
- Command execution — a hardened command tool can run a pre-approved
list of binaries (for example
gitorkubectl) with no shell, strict argument validation, and isolated environment variables. Only binaries explicitly allowed for that agent can run.
Development-only tools (local shells, debug consoles) exist for testing but are stripped from production agent builds automatically. A deployed agent only carries the tools it was configured with.
How the agent chooses tools
The runtime advertises the agent's tools to the model with their descriptions and input schemas, and the model decides which to call turn by turn. Skills add a routing layer on top:
- Attached skills are listed to the agent in a catalog of names and descriptions.
- When a request matches a skill's description, the agent loads that skill's full instructions and follows them — preferring the skill over its own default behavior.
- If no skill matches, the agent answers using its base instructions and built-in tools.
This is why a skill's description matters: it is the trigger the agent matches against. A description that states when the skill applies ("when the user asks for a weather forecast…") routes far more reliably than a bare label ("weather skill").
Every tool call the agent makes is recorded as an audit event, and sensitive tools can be gated behind human approval.