Documentation Index
Fetch the complete documentation index at: https://docs.usezombie.com/llms.txt
Use this file to discover all available pages before exploring further.
A tool is a named verb the agent inside a stage may invoke. Tools are declared in TRIGGER.md under x-usezombie.tools: — anything not on the list is unreachable, even if the model tries to call it. This page is the canonical catalogue.
x-usezombie:
tools:
- http_request
- memory_recall
- memory_store
- cron_add
23 tools are user-callable today. They group into nine categories below. For the file format, validation rules, and frontmatter, see Authoring a zombie.
Network
How a zombie talks to the outside world. Each network tool has a different relationship with network.allow: — read the column carefully before declaring one.
| Tool | What it does | network.allow: enforced? | Reach for when |
|---|
http_request | HTTPS calls (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS) to external APIs. The tool bridge substitutes credential references (${secrets.NAME.FIELD}) into headers and bodies outside the sandbox. Default response cap: 1 MB. | Yes. Off-list hosts dropped by the sandbox firewall before the request leaves. | Any third-party API. Slack, GitHub, Linear, your hosting provider, your monitoring — everything goes through this. |
web_search | Internet search across platform-managed providers (SearxNG, DuckDuckGo, Brave, Firecrawl, Tavily, Perplexity, Exa, Jina). The provider chain is hardcoded; the agent picks among them with the provider argument. | No. Provider hosts aren’t user-controllable, so they bypass network.allow: entirely. You don’t list searxng.org etc. in your network.allow: — the platform handles that. | Open-web research during a stage — finding a CVE writeup, looking up a stack trace, etc. |
web_fetch | Fetch an HTTPS page and convert it to readable markdown. | No (today). The tool is built with an empty allowlist on hosted v2, which NullClaw treats as allow-any-HTTPS. Don’t rely on network.allow: to constrain web_fetch — if you need host scoping for fetched content, gate it through http_request instead. | Pulling docs, blog posts, status pages into the agent’s context without writing a custom HTML parser. |
Three different stories on one page. The network.allow: list only governs http_request. web_search uses platform-managed search backends. web_fetch is currently unconstrained (no host filter) — this is a known limitation on hosted v2 and may tighten in a future release.
Memory
Cross-stage durable state. See Memory for the four-category model and key conventions.
| Tool | What it does | Reach for when |
|---|
memory_store | Upsert a distilled fact (key + category + body + tags). | End of every stage where the zombie learned something worth keeping. |
memory_recall | Exact-key lookup; returns the entry or empty. | Start of every stage, before reasoning. |
memory_list | Filter entries by category, tags, recency. | When the agent doesn’t know the exact key (e.g. “show me all open tickets”). |
memory_forget | Delete an entry. | Correcting stale facts; fed by zombiectl steer corrections. |
Cron
Self-scheduled future stages. The zombie sets these from inside the reasoning loop — useful for follow-ups, periodic health checks, and deferred work.
| Tool | What it does |
|---|
cron_add | Create a scheduled job. Takes either expression (cron syntax) or delay (30m, 2h) plus a command. |
cron_list | List scheduled jobs with status and next run time. |
cron_remove | Delete a scheduled job by ID. |
cron_update | Update an existing job’s expression, command, or enabled state. |
cron_run | Force-run a job immediately, regardless of schedule. |
cron_runs | Show execution history for a job. |
Agent orchestration
Lets one zombie hand work to another agent. Powerful but advanced — most zombies won’t need these.
| Tool | What it does | Reach for when |
|---|
delegate | Delegate a subtask to a specialized sub-agent (potentially a different model). Synchronous — the parent waits for the result. | The subtask benefits from a stronger model, a different system prompt, or fresh context. |
spawn | Launch a background subagent asynchronously. Returns a task ID immediately; results arrive as system messages later. | Long-running fanout that shouldn’t block the current stage. |
schedule | Richer scheduler than cron_*. Supports shell command jobs and agent prompt jobs, with optional channel routing. Actions: create, once, list, get, cancel, pause, resume. | When you need agent-as-job (vs. just a shell command), or one-shot timers, or want results routed to a specific channel. |
Browser
Three independently-declarable tools that look related but overlap awkwardly. Most operational zombies should not declare these. Prefer http_request for API calls and web_fetch for HTML extraction — both work cleanly on the headless cloud executor. The browser tools exist for desktop/local use cases that don’t translate to hosted v2.
| Tool | What it does | What it actually does on hosted v2 |
|---|
browser | Multi-action verb. The schema advertises open, screenshot, click, type, scroll, read — but only open and read are functional. screenshot redirects to the standalone tool (return ToolResult.fail("Use the screenshot tool instead")). click/type/scroll always fail (“CDP not available”). read is a curl-based HTML fetcher capped at 8 KB. | open shells out to open/xdg-open on the executor host — no display on a headless cloud worker, so this no-ops or errors. read works but is inferior to web_fetch. |
screenshot | Independent tool. Captures the executor’s screen via platform-native commands. Returns an [IMAGE:path] marker. | The hosted v2 executor is headless. There’s no display to capture, and the tool reflects that — declare only if you’re running a self-hosted executor with a display attached. |
Declaring browser does NOT unlock screenshot capabilities. They’re independent tools; the sub-action name overlap is incidental. If you want a screen capture, declare screenshot. Declaring both browser and screenshot is fine — they don’t conflict.
Git
Repository operations on the executor’s workspace directory.
| Tool | What it does |
|---|
git | Structured wrapper for status, diff, log, branch, commit, add, checkout, stash. Constrained to the executor’s workspace. |
File
The agent does not get a free shell or filesystem inside the sandbox. The one file tool exposed to zombies enforces hash-anchored edits to prevent silent overwrites.
| Tool | What it does |
|---|
file_edit_hashed | Replace lines in a file using Hashline anchors. Edits are rejected if the on-disk content has drifted from the hash the agent saw — protects against concurrent-edit races. |
Stateless utilities
Pure-function helpers — no side effects, no network, no state.
| Tool | What it does |
|---|
image | Read image metadata (format, dimensions, size). Capped at 5 MB. |
calculator | Arithmetic, logarithms, rounding, basic statistics. Use this rather than letting the model do math in prose — it’s deterministic. |
Channel routing
| Tool | What it does |
|---|
message | Send a message to a channel. If channel/chat_id are omitted, posts to the current conversation. Supports attachment markers ([FILE:...], [DOCUMENT:...], [IMAGE:...]) on marker-aware channels. |
Tools are the what (verbs the agent may invoke). Credentials are the what-with (named secrets the tool bridge substitutes into outbound calls — see Credentials). The network allowlist is the to-where (hostnames the sandbox firewall lets traffic reach).
A working http_request to Slack needs all three:
x-usezombie:
tools:
- http_request # the verb
credentials:
- slack # the secret (bot_token field)
network:
allow:
- slack.com # the destination
Drop any one and the call fails: missing tool → agent can’t even try; missing credential → tool bridge has nothing to substitute; missing host → firewall drops the request.
Validation
zombiectl install --from <path> accepts the tools: list as-is — there’s no catalogue check at install time. Unknown names surface later, when the executor builds tools for a stage: each unrecognized name gets logged as UZ-TOOL-005 (Unknown tool) and silently skipped. The agent runs with the remaining tools.
The practical consequences:
- Typos pass install. Declaring
http_requesst: (typo) won’t fail zombiectl install --from. Catch this by tailing zombiectl logs <zombie_id> after the first event and looking for the skip warning, or by spotting tool calls in the activity stream that don’t match what your SKILL.md prose expects.
- Disabled tools are also silently dropped. Setting
enabled: false on a tool entry skips it without a warning.
UZ-TOOL-005 is a log warning, not a wire response. It won’t appear as an HTTP error to a webhook caller; it’s a server-side observability signal.
When the agent tries to invoke a tool not in the zombie’s resolved tools: set, the underlying agent runtime returns a “no such tool” error to the agent in-prompt — visible in the activity-stream entry, not as a wire response. The platform registers UZ-TOOL-004 (Tool not attached) for this case but the v2 emission path stays inside the activity stream. See Error codes → Tool.
See also
- Authoring a zombie — full
TRIGGER.md schema.
- Memory — the four memory categories and how recall/store fit a stage.
- Credentials — adding the secrets the tool bridge substitutes.
- Webhooks — wiring an external system to your zombie.