Tools

v1 status: hand-written from src/tools/mod.rs. Will be generated by introspecting the tool registry — each tool’s name(), description(), and parameters_schema() — in a later iteration.

Always-on tools

These register unconditionally:

Name	Description
`shell`	Execute a shell command. Sandboxed (via the auto-detected sandbox) and command-allowlisted.
`file_read`	Read a file from the workspace
`file_write`	Write a file to the workspace
`glob_search`	Glob over workspace paths
`cron_add`	Schedule a recurring job
`cron_list`	List scheduled jobs
`cron_remove`	Remove a scheduled job
`cron_update`	Update a scheduled job
`cron_run`	Run a scheduled job ad-hoc
`cron_runs`	Inspect job run history
`memory_store`	Persist a fact to long-term memory
`memory_recall`	Hybrid lexical+vector search over memory
`memory_forget`	Delete a memory entry
`schedule`	Schedule an action
`proxy_config`	Read or update HTTP proxy config
`manage_permissions`	Owner-only. Manage channel owners, the non-owner (guest) capability ceiling, and the owner shell allow-command list — all from chat. Hard-denied to non-owners via `GuestGate::OWNER_ONLY_TOOLS`. (v0.6.75; `allow-command` target added v0.6.84)
`issue_pairing_code`	Owner-only. Mint an on-demand pairing code from chat so a new user or device can self-onboard without a daemon restart. Hard-denied to non-owners via `GuestGate::OWNER_ONLY_TOOLS`. (v0.6.82)
`git_operations`	Git commands wrapped as tool calls
`pushover`	Send a Pushover notification
`pdf_read`	Extract text from a PDF
`screenshot`	Capture a screenshot
`image_info`	Inspect image metadata
`skills_list`	List installed skills
`skill_view`	Read the prompt/metadata of an installed skill
`skills_search`	Search across installed skill prompts
`author_skill`	Write-side skill authoring (“make me a skill that does X”) — writes a new `SKILL.md` into the active profile so it loads on the next turn. Registered when an active profile exists. (v0.6.77)
`skills_install`	Install a skill from a git URL or local path
`skills_install_deps`	Run a skill’s brew/npm/uv/go/download install recipes

author_skill and skills_install register only when an active profile can be resolved (ProfileManager::active()); the fresh-install setup wizard creates one, so in practice they are present. Both route through the approval manager by name like shell.

Compile-feature-gated tools (default-on build)

Two tools are gated behind the remote-install Cargo feature. That feature is part of the default feature set — default = ["tui", "whatsapp-web", "remote-install", "kb"] in Cargo.toml — so a standard cargo build and the released binaries ship them. They only disappear from a --no-default-features build that omits remote-install.

Tool	Feature	Purpose
`ssh`	`remote-install`	Open an SSH transport (russh) and run commands on a remote host.
`pty`	`remote-install`	Drive a live tmux/pty session.

Both are owner-only (GuestGate::OWNER_ONLY_TOOLS) and hard-denied to non-owners — they run arbitrary commands with no glob-checkable single command, so a guest allowlist cannot safely bound them. Registered in all_tools_with_runtime under #[cfg(feature = "remote-install")].

Conditional tools

These only register when their gate is satisfied:

Tool	Gate
`browser_open`, `browser`	`[browser].enabled = true`
`http_request`	`[http_request].enabled = true`
`web_search_tool`	`[web_search].enabled = true` (note the `_tool` suffix)
`composio`	`[composio].api_key` is set (gives access to ~150 app integrations)
`delegate`	`[[agents]]` is configured (multi-agent dispatch)
`list_tasks`, `get_task`, `create_task`, `update_task_status`, `create_subtask`, `complete_subtask`, `review_task`, `add_comment`, `read_comments`	`[tasks].enabled = true`

Easy-mode defaults (v0.6.89, config schema v9). On a fresh install the [browser], [http_request], and [web_search] gates all default to enabled = true, and [http_request].allowed_domains defaults to ["*"] (allow-all). So browser_open / browser, http_request, and web_search_tool register out of the box unless you explicitly disable them. These defaults widen local capability only. The exposure boundary stays deny-by-default: gateway pairing, localhost bind, allow_public_bind = false, and rate limits are untouched. Defaults are defined in src/config/schema.rs (BrowserConfig / HttpRequestConfig / WebSearchConfig).

Default vs all

default_tools() — shell, file_read, file_write, glob_search. Used when the agent runs in minimal mode.
all_tools_with_runtime() — every always-on tool plus all conditionals whose gates are satisfied.

The factory functions live in src/tools/mod.rs.

Notes on validation

Tool parameter schemas (returned by parameters_schema()) are what the LLM is told about. They are not validated by the runtime at execute time — tools manually pull args via args.get("foo").and_then(...) patterns. Consequently:

Schema correctness is a discipline matter, not a runtime guarantee.
Tools handle their own missing-arg / wrong-type errors; they return ToolResult { success: false, error: Some(...) } rather than panicking.

For full parameter schemas of each tool, see the implementation at src/tools/<name>.rs.

Peripheral-contributed tools

When [peripherals] is configured, each registered board contributes additional tools via its Peripheral::tools() implementation. Common ones:

Tool	Source
`hardware_board_info`	Any registered peripheral
`hardware_memory_map`	Boards that expose a memory map
`hardware_memory_read`	Boards that expose readable memory

Boards may also contribute flash/upload tools (Arduino, Nucleo). The exact set depends on which boards are enabled — see Reference → CLI (rantaiclaw hardware, rantaiclaw peripheral) and src/peripherals/.

Skill-defined tools

Skills installed under <profile>/skills/<slug>/ can declare their own tools in SKILL.toml. These are exposed to the LLM with the prefix skill_<skill>_<tool> and run via SkillToolAdapter. Only kind = "shell" and kind = "http" are executable today; other kinds (including kind = "builtin" in legacy SKILL.md prose) are not.

See Tools & Skills for the model and Reference → Skills for the schema.