Overview

The Native Tool Belt is the set of general-purpose tools that every Allternit agent can call without installing an external server. The belt is initialized by NativeToolBelt and registers tools into a ToolRegistry, and the same tool set is also exposed through the REST API.

Base URL

The tool registry is mounted on the protected router at both /api/v1/tools and /api/tools:
Local development:

Registry primitives

Web tools

Search the web using a configurable adapter. Results are cached per query and clamped to a maximum of 10 entries. Supported providers

web_fetch

Fetch a URL and return readable text. HTML responses have scripts and styles stripped. Output is truncated at 50,000 characters by default.

Workspace tool

str_replace_editor

A file editor that operates within a single workspace root. All paths are resolved relative to the workspace and constrained to stay within it. Commands: view, str_replace, create, insert, undo, undo_edit.

System tools

bash

Execute a shell command with optional timeout (default 30s) and restart control.

code_execution

Run code in a sandboxed environment. Supports python, node, bash, and rust.

memory

Session-scoped key/value store. In-memory by default; production deployments inject a persistent store.

REST execution surface

The same tool registry is reachable over REST so desktop, web, and mobile clients can call it with the same shape.

Authentication

The execute handler requires the x-allternit-user-id header. Organization-scoped behavior (such as resolving server-side tools) uses x-allternit-organization-id or x-allternit-tenant-id.

Endpoints

The same routes are also reachable under /api/tools, /api/tools/execute, and /api/beta/approvals/:id.

List tools

Response:

Execute a tool

Request body
Response:
Failed tool executions still return HTTP 200 with success: false and an error string:

Permission policies and approvals

Tool execution can be gated by the active permission policy. A policy is an ordered list of rules that classify each request as allow, deny, or ask. The first matching rule wins; if no rule matches, the request is allowed. A rule can match by:
  • tool — exact name or glob (file.*, http.*)
  • filePath — path or prefix (/etc/*)
  • networkHost — host or wildcard (*.internal.example.com)
  • actionallow, deny, or ask
When a request matches an ask rule, the API returns HTTP 202 with an approval ID:
Approve or deny the request later:
Approvals are stored in memory for the lifetime of the API process. If the process restarts, pending approvals are lost.

Result caching

When cache: true is set on an execution request, results larger than ~4,000 serialized JSON characters include a cache_control hint:
This hint can be passed back to providers that support prompt caching. Small results omit the field entirely.

Native tool reference

The following tools are implemented by tool_routes.rs. Tools that are also registered as server-side tools for the caller’s organization take precedence over the native implementations.

Shell

Code execution

File system

System and network

Document conversion

For document_to_markdown, upload the file first with POST /api/v1/uploads and pass the returned uploadId, or pass an existing artifactId.
Long Markdown output is truncated at 30,000 characters with a note appended and truncated: true.

Error codes

Customizing execution backends

NativeToolBelt accepts injectable backends so the same tool contract works in tests, local CLI, and remote sandbox deployments: