Tools

The built-in tools every agent can call from inside its computer, and how the tool-use loop works.

Tools are how agents do real work in the world. The agent requests; its computer executes; results come back. Browser, shell, files, HTTP, and memory ship out of the box — and the agent can install more at runtime.

The built-in tools

| Family | Tool | One-liner | | --- | --- | --- | | Browser | jettson_browser_navigate | Load a URL in a headless browser | | | jettson_browser_extract_text | Pull visible text from the current page | | | jettson_browser_screenshot | Capture a PNG screenshot | | Shell | jettson_shell_run | Execute a shell command in /workspace | | Files | jettson_files_read | Read a file from the workspace | | | jettson_files_write | Write a file to the workspace | | | jettson_files_list | List directory contents | | HTTP | jettson_http_request | Outbound HTTP/HTTPS with SSRF guards | | Memory | jettson_memory_put / _get / _search / _list / _delete | Persistent knowledge |

Each tool has a dedicated reference page: Browser, Shell, Files, HTTP, Memory.

The tool-use loop

Every reasoning iteration looks like this:

text
1.  Agent receives:  task + tool definitions + prior messages
2.  Agent emits:     either text (final result) or a tool_use block
3.  Its computer:    executes the tool, gets a result
4.  Agent receives:  the tool_result, plus all prior context
5.  GOTO 2           until end_turn or iteration cap (20)

A tool result is a JSON object the agent reads as part of its next reasoning step. Errors are returned as { error: "…" } payloads — they don't crash the loop, the agent sees them and adapts.

How agents pick tools

You can:

  1. Mention specific tools by name in your task prompt — the agent treats them as suggested first moves.
  2. Describe the goal and let the agent pick. Works surprisingly well.
  3. Constrain explicitly — "Use only jettson_files_* tools. Don't call the browser."

Most production agents fall into pattern 2 — concrete goal, agent picks tools. The reasoning model is good at it.

Tool safety

Each tool has built-in guardrails:

  • Shell — 60s hard timeout, 10MB output cap, blocklist on destructive patterns (rm -rf /, fork bombs, etc.). Runs in /workspace only.
  • HTTP — refuses private-IP ranges, refuses *.jettson.dev, capped body sizes.
  • Files — path-rooted at /workspace, refuses traversal (..), 1 MB per read cap.
  • Browser — single browser per container (shared across nav calls in the run), 30s page-load timeout.
  • Memory — quota-aware; full validation on key/value/tags shape.

You don't need to teach the agent about these limits — when it hits one, the tool returns a structured error and the agent adapts on the next iteration.

Custom tools

Custom tool registration ships in a future release alongside the Node and Python SDKs (see SDKs). Until then, the built-ins cover the most common workflows; for anything else, the jettson_http_request tool can talk to your own services, and the agent can install packages it needs into its workspace at runtime.

Related