Skip to main content

Overview

Tools are capabilities the agent can invoke during a conversation. Some tools require your approval before executing (marked with πŸ”’). Some tool schemas are deferred. The active harness exposes either load_tools or native tool_search as the loader and names the required call in the system prompt. Loading only makes a schema callable on the next model step; it does not execute the tool or bypass approvals.

System & files

File write tools and set_directives are deferred. The background tool can start new background work immediately; the background deferred group is only for listing, reading, or canceling existing background tasks.

Email

Requires Gmail to be connected. Deferred group: email.

Calendar

Requires Google Calendar to be connected. Deferred group: calendar.

Google Drive

Requires Google Drive to be connected. Deferred group: google_drive.

Facts

Facts are the canonical, source-backed correctness layer. Change them through an exact plan and commit; do not use a generic memory-record mutation tool. plan_fact_changes returns the preview and plan_id; commit_fact_changes accepts only that plan_id. The server derives authority and provenance from the active session and Area.

Wiki

Wiki pages are the readable, managed projection. Read before writing, then use semantic page arguments; the backend enforces concurrency. On a conflict, reread and retry. Scheduled automations can use generic writes only below automations/; generated publishing remains reserved for an explicit owner. This group is deferred: load it with load_tools(group="wiki").

Web

Web search uses WEB_SEARCH mode (auto, exa, ddgs, none). EXA_API_KEY is only required when mode resolves to Exa.

Slack

Requires Slack to be connected. Deferred group: slack.

Automations

Deferred group: automations.

Runtime state

App control

Available only when the active session has app-control capability. These are mostly internal coordination tools. The desktop app exposes the visible results as todos, channels, session history, and status updates.

Background tasks

Deferred group: background. Agents are spawned with the always-available background tool, which returns the agent’s own session id. Results are delivered back into the parent chat automatically; use read_session to inspect an agent’s work and send_message to steer it.

Notifications

Deferred group: notifications.

MCP tools

Connected MCP server tools are deferred by server. Use load_tools(group="mcp:<server>"), for example load_tools(group="mcp:obsidian"). MCP tools still keep their own approval/mutation behavior after loading. MCP tools default to conservative external execution: approval required. Per-tool config can override that with tool_policies.<tool_name>. If a server is trusted, trust_tool_annotations=true lets Arden use MCP Tool.annotations hints such as readOnlyHint and destructiveHint; explicit tool_policies still win.

Canonical workflows

Follow the same sequence for source-of-truth work: search β†’ inspect β†’ preview β†’ mutate β†’ verify. Never invent IDs; pass stable refs returned by the previous tool.

Bounded file edit

  1. Find candidates with find_files or search_text; if has_more is true, narrow the query or continue with its cursor.
  2. read_file(path, offset, limit) the exact region and retain its revision.
  3. Call edit_file or write_file with that revision. The approval card shows the diff before the write.
  4. Treat write_conflict, not_found, and permission_denied as terminal for that attempt; follow recovery_action, re-read, and create a new preview.
  5. Verify the returned after_ref by reading the file again. Large results provide a durable raw_ref rather than disappearing at truncation.

Slack and Gmail mutation

  1. Load slack or email, search with a bounded limit, and continue only when the result says more may exist.
  2. Inspect the selected message/thread. Use its exact source_refs[].ref (channel:timestamp for Slack, account:message_id for Gmail).
  3. Draft the post, send, or reply; provide a stable idempotency_key. Approval shows the destination and bounded body preview.
  4. A successful mutation returns an effect, provider receipt, and after_ref; an uncertain result says to verify provider state before retrying.
  5. Read the returned ref to verify. For Gmail replies, reply_email preserves In-Reply-To, References, and Gmail threadId.

MCP recovery

  1. Load the exact server group with load_tools(group="mcp:<server>"); loading never executes a tool.
  2. Inspect the lossless schema and annotations. Bound list arguments and use refs from earlier results.
  3. Preview and approve external mutations unless an explicit policy says otherwise.
  4. On tool_not_loaded, load the named group; on mcp_error, follow its recovery action. Do not retry uncertain mutations without checking state.
  5. Preserve returned source_refs, raw_ref, receipts, and verification data for downstream calls.

Deferred loading examples

Skills

Obsidian should be connected as an MCP server and loaded with load_tools(group="mcp:obsidian") when needed.

Approval flow

When a tool requires approval, the desktop app shows an approval card with the tool name, arguments, preview, and options to approve or reject the call. Session/tool-specific policy overrides can skip repeated approvals when you explicitly configure them. Settings β†’ Tools can override individual tools:

Per-automation tool scoping

An automation can carry a tool scope: an allowlist of tool-name patterns that bounds what its runs may touch, applied as a hard outer gate before any other selection. Patterns are * (everything), an exact name, or a prefix* wildcard.
This is how area agents stay observe-only: they get bounded fact and wiki reads, but no fact commits, generated-page publishing, or external actions. A missing scope gives an automation only the read-only floor. Use "*" only when unrestricted tool access is intentional. Area custodians finish by calling submit_area_report. Invalid or stale reports return a tool error inside the same agent loop, so the custodian can correct the report before the automation is allowed to settle.

User-defined tools

Create custom tools in ~/.arden/tools/. Each file exports a tools mapping. Inputs must be bounded, failures typed, and stable results sourced:
Use policy=ToolPolicy(..., requires_approval=True) plus an approval= function for tools that change source-of-truth state. Use permissions=frozenset({...}) to hide a tool unless a service is configured. Restart the server after adding or changing user tools.