Jazz tool inventory

Find the tool names to use in agent restrictions and approval grants. In chat, /tools shows the tools available to the current agent. Use jazz agent edit <name> to change its selected capabilities; use deniedTools to remove a specific tool.

Risk tiers determine what runs unattended. See Approvals and the security model.

At a glance

Plus, registered per agent rather than globally:

How approval pairs work

Every tool above read-only is gated: under a policy that does not clear its level it asks first, or is declined (or parked) when nobody can answer. With no policy, or false, nothing clears. Gated tools include approval pairs and tools that ask before running directly.

The 12 approval pairs split proposing from acting: calling one does not act. It returns a description of the intended action (including a preview diff for edits), and only after approval, from a human or from the policy, does Jazz invoke the hidden execute_* counterpart. A plain gated tool has no proposal half: the executor asks with its name, risk level, and arguments, and runs the tool itself once approved.

Only the tool registered for an execute_* counterpart can ask for it. Any other tool output shaped like an approval request (an MCP server’s reply, a fetched JSON document) is refused and nothing runs.

You never call execute_* names yourself; they are hidden from the model’s tool list.

What each tool reveals

Risk is not the same question as disclosure. Risk asks what a tool can do to the machine; disclosure asks how freely its answer can be shared. The two do not correlate: read_file is read-only and can reveal anything, get_time is read-only and reveals nothing, write_file changes the machine and reveals nothing at all.

What leaves the machine

Risk and disclosure are both about this end of the call: what a tool does to your machine, and what its answer would reveal. Neither asks about the request, and for a handful of tools the request is where your material would actually leave.

Three more, absent above only because they are registered per agent rather than globally: ask_peer (high-risk), whose whole purpose is to put your model’s words in front of somebody else’s agent; request_clarification (low-risk), offered only when a peer relationship is configured, which lets the agent ask a peer one question back before answering theirs; and every MCP tool, whatever its transport: where a server outside this codebase carries the model’s arguments is not knowable from here.

This changes nothing in the terminal: approval tiers read the risk column, and a read-only tool that fetches a URL is still auto-approved under --approval-policy read-only. It matters at exactly one door: a tool listed here is never granted to another person’s agent by a disclosure tier. It has to be named in that peer’s allow, the same as a tool that writes to disk. See Security model: how the ceiling is computed.

The same holds for manage_todos, update_work_state, manage_scratchpad and spawn_subagent. They are read-only for your own runs, but they write the agent’s durable bookkeeping or start child runs, so a peer reaches them only when its allow names them.

The tools

File Management

Shell Commands

wait_for checks once before it returns. If the condition already holds, nothing is scheduled. Otherwise the call returns that first check’s exit code and output, and keeps checking as a background job (the same worker as run_background_jobs). The agent keeps working and is woken with the last check’s output when the condition holds or the time runs out. If every check returned the same exit code and output, the wake message says so and tells the agent to test the check itself before waiting again.

Where the agent is woken depends on whether the conversation is open. In an interactive chat, the chat takes the turn itself the moment it is idle: the result appears in the transcript and any approval the turn needs is asked right there. A message you are typing stays in the composer. The same goes for a register_trigger wake-up that comes due while the chat is open. With no chat open (or after you leave it, or in a piped jazz session), the turn runs unattended as before and parks on the first approval it needs, waiting for jazz runs approve.

To watch a wait live in the fullscreen terminal, press down from an empty composer to reach the pending waits and press Enter on one. Its command and recent checks (exit code, age and output of each) replace the transcript and update as checks run; Esc goes back to the conversation. Elsewhere, /waits show <number> prints the same view once. cancel_wait_for cancels the batch that wait_for created; for waits longer than 15 minutes, register_trigger suspends the run and resumes it later.

In the interactive terminal, an operator can also type ! <command> (the space after ! is required). That explicit shell escape uses the same cwd resolution, environment sanitization, denylist, timeout, interruption, and output caps as execute_command, then gives the result to the agent as context. It is not available through jazz run or remote chat surfaces.

Web Search

Web Fetch

HTTP

Todo

Memory

Memory tools are in the built-in bundle. Deny manage_memory to prevent writes, and propose_lesson to stop lesson proposals. See Memory.

/learn also gives its own pass revise_memory, which no agent receives: it queues the removal of a duplicated, contradicted or stale entry, or a rewrite of a lesson, for you to keep or drop in the same checklist.

update_work_state lives with the todo tools (always-on). It is scoped to one conversation and discarded when the task ends, unlike memory which persists across conversations. See Context management.

Workspace

Scratchpad tools are in the built-in bundle. Use them for working drafts, research material, and intermediate files that should persist across conversations.

Reminders

Opt-in per agent. Reminders persist on disk and fire later on the same surface that scheduled them. See Reminders.

For CLI-hosted agents, add_reminder installs the same real one-shot host-scheduler job (launchd on macOS, an at job on Linux) used for wake triggers, so a reminder fires even if jazz daemon isn’t running; firing sends a native OS desktop notification instead of resuming a conversation: a reminder is “notify a person,” never “resume the agent.” jazz daemon’s in-process ticker remains a fallback for hosts with neither launchd nor at. Telegram and Discord reminders are unaffected by any of this: their bots already sweep and deliver reminders as chat messages from their own in-process interval, unchanged.

Goals and loops

The agent proposes a goal when a request needs sustained work across several runs. The goal is saved as proposed and nothing runs until the user accepts the plan: chat asks right after the turn, and jazz goal accept <id> accepts it elsewhere. Subagents and goal cycles cannot propose goals. A goal’s own cycles get report_goal_cycle, which says where the goal stands (Jazz checks the claim against the cycle’s tool output), and a loop’s own runs get end_loop, which stops the loop after the run; nothing else has either, and no tool can start a loop. See Goals and loops and jazz loop.

Wake Triggers

Opt-in per agent. A trigger causes the agent to actually run again with a given prompt, resuming the exact conversation it was scheduled from: unlike a reminder, which just delivers a note to a person. See Reminders for how the two compare.

register_trigger does not depend on jazz daemon running to actually fire. Registering a trigger installs a real one-shot job with the host’s own scheduler: a launchd job on macOS, an at job on Linux: that fires the trigger by invoking jazz directly at the scheduled time, even if nothing else is running. jazz daemon’s in-process ticker remains a fallback for platforms or environments with neither launchd nor the at binary available (most containers, some CI), and scheduling with the host is always best-effort: if it fails for any reason, registration still succeeds and the ticker is the safety net.

Background Jobs

Background-job tools are in the built-in bundle. run_background_jobs starts independent shell commands in a detached worker, with bounded concurrency and retries. When all jobs finish, the agent resumes its conversation with their statuses and output.

No daemon is required to start a batch. The daemon can recover a batch whose worker stopped. If the resumed turn needs approval, it parks and sends a notification; answer with jazz runs approve <id>. See Deferred work.

Context

Tool Search

Sub Agents

Perception Delegation

Always-on. Lets an agent borrow specialist perception or generation from another model.

User Interaction

Compositions

Enable Compositions per agent to create interactive HTML pages or static images. The bundled composition skill supplies design instructions.

Browser

Enable Browser Use per agent to drive real web pages. The tools load on demand and are off by default.

browser_adopt_tab (high-risk, pair execute_browser_adopt_tab) is registered only when browser.endpoint points at a browser the user runs: it lets the agent take over one existing tab the user names, after a separate approval showing the tab’s title and URL. The agent sees only tabs it created or adopted, never the rest of the user’s browser.

Computer use (experimental)

Enable Computer use per agent to look at and act in desktop apps you grant. It is experimental, runs on macOS with Apple Silicon only, and exists only in a terminal conversation with you watching. Enabling the tools acknowledges computer use; the first successful session pins the driver digest automatically. Only a changed driver build requires computer_acknowledge_driver approval. The tools load on demand and are off by default.

What is not a built-in tool

A common and consequential misreading. These capabilities exist, but not as built-in tools: they are skills that shell out through execute_command, which is unknown:

Jazz classifies each CLI command before applying the run’s approval policy. Read-only commands may run at read-only; mailbox or calendar changes can require human approval. Grant specific commands only when you understand their scope. A grant for an entire binary such as himalaya also permits its mutation commands. See email and calendar setup.

Notes

• Editing a file another agent may change: Pass the snapshot from a text read_file unchanged to edit_file, even if you read only a line range. A stale snapshot returns StaleFileError without writing or asking for approval; read again and retry. Append reads and media attachments do not produce snapshots. Jazz serializes its own edits; writes from other programs can still conflict.
• Following a file that is still being written: read_file with sinceByte returns appended bytes, plus nextByte and inode for the next read. On truncation or rotation it restarts at byte 0 and reports the change. A nonzero sinceByte cannot be combined with startLine or endLine.
• find vs grep: find locates files by name, glob, or path pattern. grep searches inside file contents.
• Shell command approval: Jazz classifies each command as read-only, low-risk, or high-risk, then applies the active approval policy. Interactive chat shows the classification while it runs and the result afterwards. Timeouts and ambiguous classifications remain high-risk. See Approvals.
• HTTP requests and page fetches run automatically by default. http_request and web_fetch have the same global network.httpApproval policy, independent of method, risk tier, private destinations, prior untrusted content, or unattended execution. A configured URL array requires one-call approval outside its grants; approving never changes the list. Each redirect must match a grant too. Both tools strip credential/custom headers across origins, refuse forwarding bodies across origins, and cap response bytes and read time. web_fetch extracts page content as markdown; http_request preserves API response structure and supports methods, headers and bodies. See HTTP approvals.
• Other model-chosen URLs use private-destination guards. read_pdf with a URL and rendered pages resolve each hostname, check every redirect, and require approval for unlisted private addresses. Approving adds those addresses to global network.allowPrivateHosts. The same credential and body limits apply. See Secrets and egress.
• Secret values never reach the model. Files read normally, including .env and secrets.json. Every tool result is redacted before it is logged or shown: secrets Jazz holds (keyring-held peer, webhook and notify secrets included) and credential-named environment variables are replaced exactly; .env and YAML assignments, key formats, JWTs, webhook URLs and private keys by shape; and strings under secret-named keys in structured results, each as [redacted:<name>]. Tools redact before they cut or search: read_file line ranges, sinceByte offsets and caps, execute_command output caps, and grep and replace_pattern matching all work on the redacted text, so no slice splits a secret and no pattern can probe one. write_file and edit_file refuse a placeholder standing for a secret of the target file or one Jazz knows, and write_file refuses to drop a line holding a secret; change such files with edit_file around the placeholder lines. See Secrets and egress.
• Secrets the person types stay out of the model. ask_user_secret reads the value hidden and gives the model [redacted:<name>]. It is also saved to the keyring under the name the agent gives it, for later runs, which load it with use_saved_secret after you approve. The value is held in memory for the rest of the run, redacted exactly from every tool result and log line, and put back only into the arguments a tool declares for it, just before that tool runs: password of read_pdf and pdf_page_count, and command of execute_command, which then always asks a person, whose approval shows the placeholder. Any other tool or argument carrying the placeholder is refused. See Secrets the person types.
• Jazz’s own config always asks. write_file, edit_file, mv, cp and rm changing config.json or Jazz’s state under $JAZZ_HOME ask for approval under every policy, yolo included. Authored content (skills, workflows, personas, memory, workspace and generated output) follows the ordinary policy.
• Outside content arrives labelled. Results from web_fetch, web_search, http_request, read_pdf URLs, MCP tools, ask_peer, every execute_command and custom command, and read_file of a file outside the working directory come back inside an <untrusted-content> envelope that names the source, and the system prompt tells the model to read them as data. Once a run has read external content, other egress tools stop auto-approving below high-risk. Because Jazz cannot tell what a command read, that includes any shell command: after one, other egress at read-only or low-risk needs approval. See Unattended runs.
• Timeouts: 3 minutes by default per tool. Questions, secret prompts, and file pickers wait without a timeout. execute_command and wait_for accept at most 15 minutes; larger timeouts are rejected.
• Stopping a command: execute_command and custom command tools run in their own process group. Esc, a tool timeout, --timeout, SIGTERM, or a run’s maxDurationMs deadline stops the command together with every process it started: SIGTERM first, and SIGKILL 3 seconds later if it is still running, so a command can finish writing and clean up. write_file, edit_file, cp and mv replace their target in one step, so a stopped call leaves the old version or the new one, never half a file. The tool results then say which calls completed, which were interrupted, and which never started. A command that leaves a job running in the background (server &) returns as soon as the shell exits, and the job keeps running.
• Concurrency: up to 10 tools execute in parallel per iteration.
• PDF rendering: create_pdf requires Chrome. Output goes to the working directory unless an explicit path overrides it.
• Composition rendering: mode: "static" requires Google Chrome or PUPPETEER_EXECUTABLE_PATH; mode: "interactive" needs no browser. Compositions live under ~/.jazz/compositions/<session-id>/. Jazz opens a completed composition automatically only in an interactive local terminal.

Related

• Approvals: what runs without asking
• Concepts: tools: what a tool is and how to add one
• Commands and flags: --approval-policy and friends
• Agent configuration: customTools, envAllowlist, and per-agent denials
• Jazz configuration: runtime defaults and autoApprovedCommands