> ## Documentation Index
> Fetch the complete documentation index at: https://docs.idemeum.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Tools overview

> Deterministic, code-reviewed functions that perform support actions.

# What are tools?

Tools are the hands of Endpoint Care: deterministic, code-reviewed functions that perform one action each on the device. Scanning a disk, listing processes, flushing a DNS cache, repairing a keychain, reconnecting a VPN. Everything the agent does on a machine, it does through a tool.

The division of labor is strict. `Skills` decide *what* to do and *when*; tools do the actual work. The AI chooses which tool to call and with what parameters, but it cannot write commands, compose scripts, or act outside the tool set. A tool does the same thing, the same way, every time it runs.

Two conventions worth knowing:

* **Read-only counterparts.** Destructive tools ship alongside read-only siblings (`get_*_info`, `get_*_size`) that report the same diagnostics without changing anything, so skills can diagnose freely and only reach for a mutating tool when a fix is actually needed.
* **Interaction gates are tools too.** The pauses where the agent asks the user something (confirm, choose, fill a short form) are implemented as tools, which means they appear in plans, pass through the same validation, and show up in the audit trail like every other step.

The full library, with each tool's source and metadata, is published at [**github.com/idemeum/skills**](https://github.com/idemeum/skills).

# Tool metadata

Each tool carries metadata that the `guardrails` enforce automatically:

| **Property**         | **What it declares**                                                 |
| :------------------- | :------------------------------------------------------------------- |
| **Risk level**       | low, medium, or high; drives how strongly the step is gated          |
| **Destructive**      | whether it changes or removes anything                               |
| **Requires consent** | whether the user must approve before it runs                         |
| **Supports preview** | whether it can show exactly what would change before changing it     |
| **Scope**            | what it may touch (the user's own account, network settings, system) |
| **Audited**          | whether its execution is recorded in the audit trail                 |

For example, `kill_process` is medium risk, destructive, preview-capable, and consent-required, so every plan that includes it automatically pauses for a preview and the user's approval. A skill author cannot forget to add the gate and the model cannot skip it; the tool's own metadata forces it.

Tool inputs are validated against a strict schema before execution, and protected targets (system-critical processes, paths outside the user's scope) are refused by the tool itself, whatever the plan says.

# Why deterministic tools?

Many AI agents act by generating a script and running it. We deliberately don't, and the difference is:

* **Reviewable once, trusted always -** every tool is code-reviewed and tested before it ships. A generated script is new, unreviewed code every single time.
* **No path from prompt to shell -** because the model's entire vocabulary is the tool list, a manipulated or hallucinating model still cannot produce arbitrary execution. With script generation, prompt injection is code injection.
* **Gating you can automate -** risk metadata only means something when the action is known in advance. You cannot pre-declare the blast radius of code that didn't exist a second ago.
* **Same input, same result -** deterministic tools make runs reproducible, debuggable, and honestly auditable: the audit trail names exactly what ran, not a blob of one-off script to reverse-engineer.
* **Predictable failure -** tools fail with structured, expected errors that skills know how to handle, instead of a stack trace from novel code.