Build a tool by describing it: how Describe-with-AI works

An AI agent is only as useful as the things it can actually do. Answering questions is table stakes; the real value comes when the agent can check an order, book an appointment, or update a record in one of your systems. The catch has always been that connecting those systems meant engineering work — and a ticket in someone's backlog.

Hania removes that bottleneck. Alongside its pre-built integrations, it has a tool builder that lets the people closest to the work add new abilities themselves — including a Describe-with-AI option that turns a plain description, or a link to an API's documentation, into a working tool. Here's how it works and why it matters.

What a "tool" actually is

In Hania, a tool is a specific action an agent can take — "look up an order," "create a ticket," "check availability." Each tool connects to an API (a service's programmatic interface) and has a clear set of inputs. When the agent decides it needs that action mid-conversation, it calls the tool, gets a result, and uses it to keep helping the customer.

You don't have to start from scratch every time: Hania ships with pre-built integrations for popular services, and you can connect those in a few clicks. The tool builder is for everything else — the systems specific to your business.

Two ways to build one

You can build a tool the hands-on way — point it at an endpoint, set the inputs, and configure how it authenticates. But the faster path for most people is Describe with AI: tell Hania what the tool should do, or paste a link to the API's documentation, and it assembles the tool for you — working out the request and the inputs the agent will need to provide.

That shift matters because it moves tool-building out of the engineering queue. The person who actually understands the workflow — in support, operations, or sales — can add the capability without waiting on a developer.

Test it before your agent touches it

A new tool is only trustworthy if you can see it work first. Hania lets you run the tool and inspect the response before any agent is given access to it. You confirm it does what you expect, then enable it — rather than discovering a problem live, on a customer call.

Built to behave in production

Once a tool is live, a few things happen automatically so it holds up under real use:

• Typed inputs, validated. Every call is checked against a schema, so the agent calls the tool with the right shape of data.
• Automatic retries. If a call fails, the agent retries until it succeeds, within the timeout you set — instead of giving up at the first hiccup.
• Guardrails for risky actions. Built-in checks flag dangerous operations, with safeguards you can require before an agent runs them.

Why this changes who can build agents

The most capable agents tend to be the ones wired into a business's real systems. When connecting those systems requires engineering for every change, agents stay shallow. When the people closest to the customer can add a tool by describing it, agents get deep fast — and they keep up as your processes change. That's the real unlock: not "no-code" as a buzzword, but the ability for the right person to give the agent a new skill the moment it's needed.

Getting started

Open the tool builder, describe what you need (or paste an API doc link), test it, and grant it to an agent. See tools & integrations for more, or read why an agent should read the result before it acts.

Common questions