Skip to main content

Tools

A tool is the lowest-level abstraction in Autessa: one specific, executable action — call an API, run a script, query AutessaDB, send an email. Agents accomplish work by choosing and invoking tools, so well-named, well-described tools are the foundation of every workflow you build.

What it's for​

If you think of a workflow as a flow chart, a tool is a single node — the smallest building block of automation. Tools are reusable: the same GetWeather tool can serve a chat agent, an AutessaDB trigger, a scheduled job, or a direct API call.

From the dashboard sidebar, open Agentic Workflows → Tools. The list has ownership tabs (Owned By Me / Shared With Me / Company Wide), search, and type/tag filters.

View Tools →

Key concepts​

Name and description matter​

Agents read a tool's name, description, and argument descriptions to decide when to call it and what to pass. A tool that gets the weather should be named something like GetWeather (names allow letters, numbers, and underscores — no spaces), with a description covering what it does and when to use it.

Tool types​

Every tool has a type that determines how it executes and what its configuration looks like. The type selector organizes roughly 300 types into categories — Core Tools, AutessaDB, Communication, File Management, Social Media, Search & Utilities, CRM, Accounting & Finance, and more. A few foundational ones:

  • Autessa Script — a scripting language built on top of JavaScript, for when you need full custom logic. See the AutessaScript documentation.
  • API Call — make a GET, POST, or PATCH request to any API, whether you host it or someone else does (for example, a weather API).
  • LLM Call — run a prompt template against an LLM, with dynamic fields filled from arguments; great for summarization or generation steps.
  • Connector-backed types — Gmail, Google Calendar, QuickBooks, Notion, and many more, each executing against a connector you've linked.

For the full catalog with every configuration field, see the Tool Types reference.

Arguments and placeholders​

Arguments are the values passed to the tool dynamically at call time. In the collapsible Arguments panel on the left of the tool editor, each argument gets a name, a type (String, Number, or Boolean), a description, and a required flag. For a weather tool, you might define latitude and longitude.

Write a detailed description for every argument — like the tool description, this is what the model reads when deciding what to pass.

Inside the type-specific configuration, reference arguments and environment variables with @@{variableName} placeholders. Typing @@ in any config field opens an autocomplete over your arguments, private arguments, prompt variables, and environment variables; placeholders are substituted at execution time.

Private arguments​

The Arguments panel has a second tab: Private. Private arguments come into play when an agent uses the tool and needs a value you don't want an LLM involved in collecting — a credit card number, for example. They're collected directly from the user in-memory and are never stored in any Autessa history.

Private arguments are never stored in any history. When collecting sensitive data from a user, use private arguments.

Because private arguments are collected via a hardcoded question rather than by the model, the Message to User is what matters most — make it a clear instruction for what to provide. Each private argument also requires validation: either a regex pattern (e.g. ^[A-Za-z0-9-_]+$) or a comma-separated list of allowed values, so you can guarantee the input arrives in the format you expect. Private arguments are always required strings.

How to create a tool​

  1. On the Tools page, click Add New Tool → Create New Tool. (You can also bulk-create tools from a connected MCP server.)
  1. Give it a name that's intuitive to what it does and a detailed description of what it does and when to use it, then click Create Tool — you land in the tool editor.
  2. Pick the tool type from the searchable category tree and fill in its configuration (endpoints, scripts, queries, connector selection — whatever the type requires).
  3. Define arguments for every dynamic input, using @@{argName} placeholders in the config where the values should land.
  4. Save. From the Manage menu you can share the tool, clone it, or publish a version (see Versions).

How to test a tool​

  1. After saving, click Execute Tool in the top right of the editor. A panel opens with one input per argument (private arguments show their Message to User).
  2. Run it either way:
    • Execute Tool — a plain request/response execution.
    • Execute with Streaming — runs over a live connection with a console of timestamped status updates. Streaming is useful for longer-running tools, where you can stream progress updates to the user during execution.
  3. Review the result: success/failure badge, elapsed time, the returned data, and — for Autessa Script tools — the execution logs.

Let the copilot build it​

You don't have to configure tools by hand. The Autobot button on the Tools page opens the Agentic Copilot — describe the tool you want in plain language and it proposes a complete tool definition you review and apply.

Sharing and access levels​

Every tool starts private to its owner. Share it with specific teammates — each at their own access level — or company-wide at a single level for everyone. What each level allows:

LevelWhat it lets a teammate do
READView the tool, its versions, and its sharing details, and test-run it
WRITEEdit the draft
PUBLISHPublish and roll back versions
ADMINShare and delete the tool

The owner always has ADMIN implicitly; transferring ownership is owner-only.