Common Patterns
List available tools with GET /api/tools to see both builtin and custom tools. Create custom tools with a clear description and input schema — agents use the description to decide when to call the tool. Assign tools to agents via the agent tools API (POST /api/agents/{id}/tools).GET /api/tools
List all tools (builtin: database_query, database_write, http_request, code_execute, storage_read, storage_write, web_search, web_scrape + custom).POST /api/tools
Create a custom tool. Required:name, description, type, input_schema. The route also accepts an optional config object — for HTTP-callable tools, the runtime reads config.endpoint, config.method (default POST), config.headers, and config.timeout_seconds when an agent invokes the tool.
Display name; agents see this when deciding to call the tool.
Free-text description; the LLM uses it to decide when to call the tool.
Free-form tag (≤50 chars). Stored verbatim; not used by runtime dispatch. Pick something descriptive (e.g.
http).JSON Schema for the tool’s arguments. Not validated at create-time; passed straight through.
Tool-specific config. For custom HTTP tools, set
{ endpoint, method?, headers?, timeout_seconds? } here — that’s where the runtime reads them.Top-level
endpoint_url / method / headers are silently dropped at create-time — only name, description, type, input_schema, and config are persisted. type is stored as a free-form String(50); the runtime does NOT switch on it. Agent-tool dispatch uses the assignment’s own tool_type (builtin vs custom), not the Tool’s type field.GET /api/tools/
Get a tool definition by ID.Tool ID
PUT /api/tools/
Update a custom tool.Tool ID
DELETE /api/tools/
Delete a custom tool.Tool ID
Error Responses
Tool routes return{"error": "<message>"}.
| Status | Description |
|---|---|
| 400 | Missing required field (name, description, type, or input_schema) on POST |
| 404 | No tool exists with the given ID |