agent0/agents/gunnar/memory/default/index.pkl

ۥ
kŒ&langchain_community.docstore.in_memory”ŒInMemoryDocstore”“”)�”}”Œ_dict”}”(Œ
6SSHP1uj89”Œlangchain_core.documents.base”ŒDocument”“”)�”}”(Œ__dict__”}”(Œid”hŒmetadata”}”(Œarea”Œ	fragments”Œ	timestamp”Œ2026-03-08 11:40:50”hhuŒpage_content”Œmodel not found”Œtype”ŒDocument”uŒ__pydantic_extra__”NŒ__pydantic_fields_set__”�”(hhh�Œ__pydantic_private__”NubŒ
whP4OBJxLx”h
)�”}”(h
}”(Œid”hŒmetadata”}”(Œsource”Œ2/a0/knowledge/main/tool_call_reference_examples.md”Œarea”Œmain”Œsource_file”Œtool_call_reference_examples.md”Œsource_path”h&Œ	file_type”Œmd”Œknowledge_source”ˆŒimport_timestamp”Nh"hŒ	timestamp”Œ2026-04-09 16:19:13”uŒpage_content”X# Tool Call Reference Examples

These examples are intentionally short and high signal so tool-call shape guidance
can live in knowledge without bloating the default prompt stack.

## 1) Namespaced tool (`text_editor`) vs non-namespaced tool (`code_execution_tool`)

- `text_editor` requires method in `tool_name`:
  - `text_editor:read`
  - `text_editor:write`
  - `text_editor:patch`
- `code_execution_tool` uses a plain tool name plus behavior in `tool_args.runtime`.

### Example A: read file lines with namespaced tool

```json
{
  "tool_name": "text_editor:read",
  "tool_args": {
    "path": "/workspace/agent-zero/README.md",
    "line_from": 1,
    "line_to": 60
  }
}
```

### Example B: run shell command with `code_execution_tool`

```json
{
  "tool_name": "code_execution_tool",
  "tool_args": {
    "runtime": "terminal",
    "session": 0,
    "reset": false,
    "code": "pwd"
  }
}
```

### Example C: poll ongoing terminal output

```json
{
  "tool_name": "code_execution_tool",
  "tool_args": {
    "runtime": "output",
    "session": 0
  }
}
```

## 2) Memory tools use plain names and structured args

```json
{
  "tool_name": "memory_load",
  "tool_args": {
    "query": "tool argument format",
    "limit": 3,
    "threshold": 0.7
  }
}
```

## 3) Subordinate tool booleans are JSON booleans

```json
{
  "tool_name": "call_subordinate",
  "tool_args": {
    "profile": "",
    "message": "Review this patch for edge cases.",
    "reset": true
  }
}
```

Use these examples as structure references only. Adapt arguments to the current task.”Œtype”h	uhNh�”(h"h#h2�hNubŒ
nf8PB1IWKX”h
)�”}”(h
}”(h"h6h#}”(h%Œ)/a0/knowledge/main/about/configuration.md”h'h(h)Œconfiguration.md”h+h;h,Œmd”h.ˆh/Nh"h6h0Œ2026-04-09 16:19:13”uh2X}# Agent Zero - Configuration Reference

## LLM Roles

Agent Zero uses three configurable LLM roles:

| Role | Purpose |
|------|---------|
| `chat_llm` | Primary model for all agent reasoning, tool use, and the Browser Agent |
| `utility_llm` | Secondary model for internal framework tasks: memory summarization, query generation, history compression, memory recall filtering |
| `embedding_llm` | Produces vector embeddings for memory and knowledge indexing |

The utility model handles high-volume, lower-stakes operations and can be a cheaper/faster model than the chat model. The Browser Agent uses the effective chat model resolved by `_model_config`, including per-chat overrides and the chat model vision flag. Changing the embedding model invalidates the existing vector index - the entire knowledge base is re-indexed automatically.

## Model Providers

Providers are defined in `conf/model_providers.yaml`. All chat and embedding providers go through LiteLLM, which normalizes the API interface. Supported chat providers (as of v0.9.8):

- Agent Zero API (a0_venice) - hosted service with no API key required for basic use
- Anthropic, OpenAI, OpenRouter, Google (Gemini), Groq, Mistral AI
- DeepSeek, xAI, Moonshot AI, Sambanova, CometAPI, Z.AI, Inception AI
- Venice.ai, AWS Bedrock, Azure OpenAI
- GitHub Copilot, HuggingFace
- Ollama, LM Studio (local models)
- Other OpenAI-compatible endpoints (custom `api_base`)

Embedding providers: OpenAI, Azure, Ollama, LM Studio, HuggingFace, Google, Mistral, OpenRouter (via OpenAI-compat), AWS Bedrock.

### Model Naming Convention

| Provider | Format |
|----------|--------|
| OpenAI | model name only (`gpt-4.1`, `o4-mini`) |
| Anthropic | model name only (`claude-sonnet-4-5`) |
| OpenRouter | `provider/model` (`anthropic/claude-sonnet-4-5`) |
| Ollama | model name only (`llama3.2`, `qwen2.5`) |
| Google | model name only (`gemini-2.0-flash`) |

## Agent Profiles

Profiles are in `agents/<profile>/`. Each profile can override any prompt fragment from the base `prompts/` directory. Built-in profiles:

| Profile | Description |
|---------|-------------|
| `default` | Base template for creating new profiles |
| `agent0` | Top-level general assistant; human as superior; delegates to specialized subordinates |
| `developer` | "Master Developer" - software architecture and full-stack implementation focus |
| `researcher` | "Deep Research" - research, analysis, and synthesis across academic and corporate domains |
| `hacker` | Red/blue team; penetration testing; Kali tools focus |
| `_example` | Minimal example for building custom profiles |

Custom profiles go in `usr/agents/<profile>/` to survive framework updates.

## Plugin System

Plugins are discovered from `plugins/` (framework plugins) and `usr/plugins/` (user plugins). Each plugin requires a `plugin.yaml` with at minimum: `name`, `description`, `version`.

### Activation

- **Global activation**: enabled/disabled for all contexts via the Plugins settings panel
- **Scoped activation**: enabled/disabled per project or per agent profile via the plugin Switch modal
- Activation state stored as `.toggle-1` (ON) and `.toggle-0` (OFF) files in the plugin's config dir

### Built-in Framework Plugins

| Plugin | Purpose |
|--------|---------|
| `_memory` | Memory and knowledge pipeline, recall, consolidation |
| `_code_execution` | Terminal and code execution tool |
| `_text_editor` | Structured file read/write/patch tool |

## Environment Variable Configuration

Any setting can be set via environment variable using the `A0_SET_` prefix. This is the primary mechanism for automated deployment and container configuration.

Format: `A0_SET_<setting_name>=<value>`

Examples:
```
A0_SET_chat_model_provider=anthropic
A0_SET_chat_model_name=claude-sonnet-4-5
A0_SET_utility_model_provider=openai
A0_SET_utility_model_name=gpt-4o-mini
A0_SET_embedding_model_provider=openai
A0_SET_embedding_model_name=text-embedding-3-small
```”h4h	uhNh�”(h"h#h2�hNubŒ
p7dsTb3zYn”h
)�”}”(h
}”(h"hAh#}”(h%h;h'h(h)h<h+h;h,h=h.ˆh/Nh"hAh0h>uh2X×These can be set in the `.env` file at the project root or passed as Docker `-e` flags during container creation.

## Key Behavioral Settings

| Setting | Effect |
|---------|--------|
| `agent_knowledge_subdir` | Which knowledge subdir to load (default: `custom`, resolved to `usr/knowledge/`) |
| `memory_recall_interval` | How many loop iterations between automatic memory recalls |
| `memory_results` | Number of memory chunks returned per recall query |
| `memory_threshold` | Similarity threshold for memory recall (0-1); lower = more results, potentially less relevant |
| `auth_login` / `auth_password` | Web UI authentication credentials |
| `agent_temperature` | LLM temperature for the chat model |

Settings are stored in `usr/settings.json` and managed through the Settings page in the web UI. The settings page also provides: API key management (multiple keys per provider with round-robin), backup/restore, external services (tunnels, MCP, A2A), and memory management.”h4h	uhNh�”(h"h#h2�hNubŒ
VXhrNQ3usP”h
)�”}”(h
}”(h"hHh#}”(h%Œ(/a0/knowledge/main/about/capabilities.md”h'h(h)Œcapabilities.md”h+hMh,Œmd”h.ˆh/Nh"hHh0Œ2026-04-09 16:19:13”uh2XW# Agent Zero - Capabilities Reference

## Code Execution

The agent can write and execute code in any language available in the Docker container. The execution environment is a Kali Linux container with two Python runtimes:
- `/opt/venv-a0` (Python 3.12) - the Agent Zero framework runtime
- `/opt/venv` (Python 3.13) - the agent's execution runtime (default for agent-run code)

The agent installs packages into the execution runtime (`/opt/venv`) via `pip install`. Packages needed by the framework itself must target `/opt/venv-a0`.

Supported runtimes for code execution: Python, Node.js, Bash/shell. Other languages (Go, Rust, PHP, etc.) can be used if the compiler/runtime is installed in the container.

Code runs in the terminal with real-time output streaming. Long-running processes, background jobs, and interactive sessions are supported. The agent can pause and resume code execution and interact with running processes.

## Terminal and System Operations

The agent has full root access to the Kali Linux Docker container. It can:
- Install packages via `apt`, `pip`, `npm`, and other package managers
- Create, read, write, move, and delete files anywhere in the container
- Run any system command, manage processes, set up services
- Access the network (HTTP requests, SSH, port scanning, etc.)
- Use Kali Linux security tools pre-installed in the container

## Skills (SKILL.md Standard)

Skills are structured markdown files that provide contextual expertise for specific tasks. When a skill is relevant to the current task, it is loaded into the agent's context and followed as a set of instructions. Skills are discovered from:
- `usr/skills/` (user-added skills)
- Project-scoped skills in `.a0proj/skills/`
- Skills imported via the web UI

Skills follow the open SKILL.md standard, making them portable across tools that support it. The agent executes skill instructions using `code_execution_tool` or `skills_tool`.

## Projects

Projects provide isolated workspaces with their own:
- Working directory (`usr/projects/<name>/`)
- Memory and knowledge scope
- Custom agent instructions (`.a0proj/agent.instructions.md`)
- Secrets and credentials (stored encrypted, not visible in agent context)
- MCP server configurations
- Git repository (can be cloned directly with authentication)

When a project is active, the agent's file operations, memory, and knowledge are scoped to that project. Projects prevent context bleed between separate work streams.

## Knowledge Base Access

The agent has automatic access to its knowledge base via similarity search. Knowledge is indexed from `knowledge/` (framework-level) and `usr/knowledge/<subdir>/` (user-level). The agent does not need to explicitly query knowledge - relevant content is surfaced automatically with memory recall. The `knowledge_tool` can also be called explicitly for targeted lookups.

## Multi-Agent Delegation

The agent can spawn subordinate agents with the `call_subordinate` tool. Subordinates can be given:
- Specific prompt profiles (`developer`, `researcher`, custom profiles)
- A defined role and task scope
- Access to the same tool set

Delegation is used to: parallelize work, maintain clean context per task, apply specialized profiles, and isolate long subtasks from the main context.

## Document Query

The `document_query_tool` can load and query arbitrary documents (local files or URLs) using a separate RAG pipeline. Unlike the knowledge base (which is pre-indexed), this tool indexes documents on demand with a configurable chunk size. Useful for analyzing large documents, codebases, or external content without polluting the persistent knowledge store.

## Scheduler

The agent can schedule tasks to run at specified times or intervals using the scheduler tool. Scheduled tasks run in the background with their own agent instances. Tasks are managed via the Scheduler UI in the web interface.

## External API and MCP”h4h	uhNh�”(h"h#h2�hNubŒ
15omi5DC80”h
)�”}”(h
}”(h"hSh#}”(h%hMh'h(h)hNh+hMh,hOh.ˆh/Nh"hSh0hPuh2XÙ## External API and MCP

Agent Zero can act as both an MCP server and an MCP client:
- As an **MCP server**: exposes agent capabilities to other MCP-compatible clients
- As an **MCP client**: uses tools from external MCP servers (configured per project or globally)

An external REST API is available for programmatic task submission. Agent-to-Agent (A2A) protocol is supported for inter-system agent communication.

## Limitations

- **No persistent state between chats** unless explicitly memorized or saved to files.
- **Context window**: long conversations are summarized automatically, which can lose detail.
- **Memory recall is approximate**: similarity search may miss relevant memories or surface irrelevant ones.
- **No GUI interaction** outside the browser agent (which is separate from the main agent).
- **Container boundary**: the agent cannot affect systems outside the Docker container unless network access or volume mounts are configured.
- **Model capability ceiling**: tool usage quality and reasoning depth are bounded by the underlying LLM. Small models may struggle with complex multi-step tool use.
- **No real-time data** beyond web search. The agent's own knowledge cutoff is the underlying model's training cutoff.”h4h	uhNh�”(h"h#h2�hNubŒ
1hrEHvxw1S”h
)�”}”(h
}”(h"hZh#}”(h%Œ0/a0/knowledge/main/about/setup-and-deployment.md”h'h(h)Œsetup-and-deployment.md”h+h_h,Œmd”h.ˆh/Nh"hZh0Œ2026-04-09 16:19:13”uh2Xh# Agent Zero - Setup and Deployment

## Docker Deployment (Standard)

Agent Zero is distributed as a Docker image: `agent0ai/agent-zero`.

```bash
docker pull agent0ai/agent-zero
docker run -p 50001:80 agent0ai/agent-zero
```

The web UI is then accessible at `http://localhost:50001`. The container exposes port 80 internally; map any host port to it.

## Persistence

All user data lives in `/a0/usr/` inside the container. Without a volume mount, data is lost when the container is removed.

Map `/a0/usr` to a host directory for persistence:
```bash
docker run -p 50001:80 -v /path/on/host:/a0/usr agent0ai/agent-zero
```

Contents of `/a0/usr/`:
- `settings.json` - all configuration including API keys and model settings
- `memory/` - FAISS vector indexes and knowledge import state
- `knowledge/` - user-added knowledge files
- `agents/` - custom agent profiles
- `plugins/` - user plugins
- `projects/` - project workspaces
- `work/` - default working directory for agent file output

## Configuration After Start

On first run, open Settings (gear icon) and configure:
1. **API Keys** - add at least one provider API key under the relevant provider section
2. **Chat Model** - select provider and model name for the primary LLM
3. **Utility Model** - select a cheaper/faster model for internal tasks
4. **Embedding Model** - select embedding provider and model (required for memory and knowledge)

Settings are saved to `usr/settings.json` immediately on change.

## Updating Agent Zero

The recommended update process is to use Self Update:
1. Open **Settings UI → Update** tab
2. Open **Self Update**
3. Wait for the update checker to see if you have the latest version or if there's an available update

You'll also be prompted through the UI when a new A0 version is released. Note that backups are automatically managed internally during the self-update process.

### Updating from Pre-v0.9.8

If upgrading from v0.9.8 or earlier, the architecture has significantly changed. You must use the new install scripts and manually migrate your data:
1. Backup your existing `usr/` directory.
2. Run the Quick Install script (`curl -fsSL https://bash.agent-zero.ai | bash` for macOS/Linux or `irm https://ps.agent-zero.ai | iex` for Windows).
3. Copy your backed-up `usr/` contents into the new installation's `a0/usr/` directory to preserve your settings, memory, and plugins.

## Remote Access

### Flare Tunnel (recommended for external access)
Settings → External Services → Flare Tunnel → Create Tunnel

This generates a public HTTPS URL without requiring firewall changes or a static IP. Set a username and password before creating the tunnel to enable authentication.

### Local Network
Access from other devices on the same network using the host machine's IP:
`http://<host-ip>:<mapped-port>`

### Microsoft Dev Tunnels
Supported as an alternative to Flare for users in Microsoft environments. Configure under External Services in Settings.

## Mobile Access

Agent Zero is a Progressive Web App (PWA). On mobile, open the web UI URL in a browser, then add to home screen for an app-like experience. Works with both local network and tunnel URLs.

## Common Troubleshooting

**Agent responds but no memory/knowledge recall:**
- Check that an embedding model is configured (provider + model name)
- Verify the embedding provider API key is set
- Embedding model changes require re-indexing; this happens automatically but takes time on first run

**"Model not found" or API errors:**
- Verify the model name matches the provider's naming convention exactly
- Check that the API key has access to the requested model
- For OpenRouter, model names must include the provider prefix (`anthropic/claude-sonnet-4-5`)

**Container starts but web UI unreachable:**
- Confirm the host port mapping in `docker ps`
- Check that no firewall rule blocks the mapped port
- The container needs a few seconds to initialize on first start”h4h	uhNh�”(h"h#h2�hNubŒ
zY9364W5fn”h
)�”}”(h
}”(h"heh#}”(h%h_h'h(h)h`h+h_h,hah.ˆh/Nh"heh0hbuh2Xª**Knowledge files not being recalled:**
- Supported formats: `.md`, `.txt`, `.pdf`, `.csv`, `.html`, `.json`
- Files must be in `knowledge/` (framework level) or `usr/knowledge/<subdir>/`
- The configured `agent_knowledge_subdir` must match the subdir where files are placed
- Re-indexing is triggered automatically when file checksums change

**Ollama / local model setup:**
- Ollama must be running and accessible from inside the Docker container
- Use `http://host.docker.internal:<port>` as the API URL for Ollama (not `localhost`)
- Pull the model first: `ollama pull <model-name>`

## Development Setup (non-Docker)

```bash
git clone https://github.com/agent0ai/agent-zero
cd agent-zero
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
pip install -r requirements2.txt
python run_ui.py
```

The dev server runs on `http://localhost:5000` by default. User data is written to `usr/` in the project root.”h4h	uhNh�”(h"h#h2�hNubŒ
dRat4HaLyj”h
)�”}”(h
}”(h"hlh#}”(h%Œ$/a0/knowledge/main/about/identity.md”h'h(h)Œidentity.md”h+hqh,Œmd”h.ˆh/Nh"hlh0Œ2026-04-09 16:19:13”uh2Xè
# Agent Zero - Identity and Design Philosophy

## What Agent Zero Is

Agent Zero is an open-source, general-purpose agentic framework. It is not pre-programmed for specific tasks and has no fixed capability set beyond the basics. Its defining characteristic is that it grows and adapts as it is used - accumulating knowledge, solutions, and behaviors through persistent memory and user customization.

The framework has been created by Jan Tomášek and is maintained by the Agent Zero dev team and the community. Source code lives at github.com/agent0ai/agent-zero.

## Core Design Principles

**No hard-coding.** Almost nothing in the framework is fixed in source code. Agent behavior, tool definitions, message templates, and response patterns are all controlled by files in the `prompts/` directory. Changing the prompts changes the agent - fundamentally if needed.

**Transparency.** Every prompt, every message template, every tool implementation is readable and editable. There are no hidden instructions or black-box behaviors. The agent can be fully audited.

**Computer as a tool.** Agent Zero does not have a library of pre-built skill functions. Instead, it uses the operating system directly - writing code, running terminal commands, and creating tools on demand. The terminal is the primary interface to everything.

**Organic growth.** The agent accumulates knowledge through experience. Facts, solutions, discovered patterns, and useful code are stored in memory and recalled in future conversations. The agent becomes more effective at tasks it has done before.

**Prompt-driven behavior.** The `prompts/` directory is the control plane. System prompts, tool instructions, framework messages, and utility AI prompts are all there. The agent's behavior is as good as its prompts.

## Project Context

- **Repository**: github.com/agent0ai/agent-zero
- **License**: Open source
- **Primary author**: Jan Tomášek
- **Community**: Discord (discord.gg/B8KZKNsPpj), Skool community, YouTube channel
- **Documentation**: docs/ folder in the repository; deepwiki.com/agent0ai/agent-zero for AI-generated docs
- **Current version**: v0.9.8

## Relationship With the User

Agent Zero treats the human user as its top-level superior in the agent hierarchy. The user is functionally indistinguishable from a superior agent - they give tasks, receive reports, and can intervene at any time. The agent is not a chatbot that answers questions; it is an executor that solves tasks using whatever means are available to it.

The framework is a personal tool, not a service. It runs locally (or on user-controlled infrastructure) and has access to the user's files, credentials, and systems as configured. This makes it powerful and requires the user to understand what they are delegating.”h4h	uhNh�”(h"h#h2�hNubŒ
aSaAjoJbVs”h
)�”}”(h
}”(h"hwh#}”(h%Œ(/a0/knowledge/main/about/architecture.md”h'h(h)Œarchitecture.md”h+h|h,Œmd”h.ˆh/Nh"hwh0Œ2026-04-09 16:19:13”uh2XF# Agent Zero - Internal Architecture

## The Agent Loop (Monologue Cycle)

Each agent runs a continuous monologue loop. On each cycle the agent receives its current context (system prompt + message history), produces a JSON response (thoughts, headline, tool name, tool args), and the framework executes the named tool. The tool result is appended to history and the loop continues until the agent calls `response` to deliver a final answer to its superior.

The loop handles: message history management, context window limits (via summarization), memory recall injection, intervention from superiors, and error recovery (misformat retries, tool-not-found handling).

## Context and State

`AgentContext` (defined in `agent.py`) is the central state container for a conversation. It holds:
- Agent number and identifier
- Message history
- The active agent profile and prompt configuration
- Reference to memory, knowledge, and tool systems
- Project context if a project is active
- `extras` dict - additional content injected into the system prompt each turn (memories, solutions, agent info, workdir structure)

Each WebSocket session connects to one `AgentContext`. Multiple concurrent chats run in separate contexts. The framework is initialized in `initialize.py` and the server entry point is `run_ui.py`.

## Prompt Assembly

System prompts are assembled from fragment files on each loop iteration. The main system prompt is `prompts/agent.system.main.md`, which includes sub-prompts via `{{ include "filename.md" }}` directives. Agent profiles (in `agents/<profile>/prompts/`) can override individual fragments. This means a subordinate with the `developer` profile gets a different role and communication section while sharing the same tool list and solving workflow as the base agent.

Prompt fragments are in `prompts/`. Plugin system prompts are in `plugins/<plugin>/prompts/`. The assembled system prompt is dynamic - it changes based on profile, active project, loaded tools, recalled memories, and injected extras.

## Multi-Agent Hierarchy

The hierarchy is a tree with the human user at the root. Each node is an agent instance running in its own context. A superior calls `call_subordinate` with a message and optional profile name; this creates a new `AgentContext` and runs the subordinate agent's loop until it returns a response.

Agent 0 is always the top-level agent whose superior is the user. When Agent 0 delegates a task to a subordinate, that subordinate can itself delegate further. There is no enforced depth limit. Agents share the same tool system but each has its own isolated context and history.

Subordinates can be given specific prompt profiles (`developer`, `researcher`, or any custom profile in `agents/`). Profiles change the role, communication style, and available instructions without changing the underlying framework.

## Memory and Knowledge Pipeline

### Knowledge (vector DB, read-only)
Knowledge files (in `knowledge/` and `usr/knowledge/`) are loaded when a memory DB is initialized (normally at the start of the first monologue in a chat), embedded, and stored in a FAISS vector index per memory subdir. Files are tracked by checksum; only changed files are re-indexed. Supported formats: `.md`, `.txt`, `.pdf`, `.csv`, `.html`, `.json`.

The memory areas are:
- `main` - general knowledge and facts (files in knowledge root or `main/` subdir)
- `fragments` - partial or supplementary knowledge
- `solutions` - known solutions to problems

### Recall (automatic, per conversation turn)
The `RecallMemories` extension runs every N loop iterations (configurable). It queries the vector store using either the raw conversation or a utility-LLM-generated search query. Results from `main` and `fragments` areas plus `solutions` are injected into `loop_data.extras_persistent`, which gets rendered into the system prompt via `agent.context.extras.md` template.”h4h	uhNh�”(h"h#h2�hNubŒ
bHL9JyLQRw”h
)�”}”(h
}”(h"h‚h#}”(h%h|h'h(h)h}h+h|h,h~h.ˆh/Nh"h‚h0huh2XóThe agent sees recalled memories as a section in its system prompt labeled "Memories on the topic". The agent is instructed not to over-rely on them.

### Agent memory (read-write, via memorize tool)
The agent can explicitly save facts, solutions, and code snippets using the `memorize` tool. These are stored in the same FAISS index under the `main` or `solutions` area and recalled in future conversations. Memory can also be consolidated (summarized) and managed through the Memory Dashboard in the web UI.

## Tool System

Tools are Python classes in `python/tools/` that inherit from `Tool`. Each tool implements an `execute()` async method. Tools are discovered at startup and registered in the agent's tool list (rendered into the system prompt as `{{tools}}`). The agent names a tool in its JSON response; the framework finds and calls it.

Plugin tools can be added in `plugins/<plugin>/tools/` or `usr/plugins/<plugin>/tools/` without modifying core files.