Tool Designer

In addition to built-in tools, Simple Agent Designer allows you to create custom tools using the Tool Designer. Custom tools extend the capabilities of your agents with business-specific operations.

Accessing the Tool Designer

From the Agent Role Center, choose Tool Designer under the Agent Designer section, or
Search for Tool Designer in the Tell Me search bar

The Tool List page opens, showing all custom tools.

What is a Custom Tool?

A custom tool is a function definition that you create for your agents to use. Each custom tool has:

A name — a unique identifier that the AI uses to call the tool (max 30 characters)
A description — explains what the tool does, so the AI can decide when to use it (max 100 characters)
Parameters — the inputs the tool expects, with types and descriptions
An implementation — an AL script, stored with the tool, that runs when the tool is called

Custom tools appear alongside built-in tools in the agent's tool catalog. The AI model treats them identically to built-in tools.

Unlike built-in tools, there is no OnToolCall (or OnToolCallEx) event subscriber to write. A custom tool is entirely defined in the Tool Designer: its metadata, its parameters, and its AL script. The script is compiled and executed at runtime by the AL Compiler and Interpreter dependency.

Creating a Custom Tool

Step 1: Define the Tool

Open the Tool List (page Tool List)
Choose New to create a new tool — this opens the Tool Designer Card
Fill in the tool definition:

Field	Type	Description	Example
Name	Text, max 30	Unique tool identifier (no spaces, lowercase recommended)	`check_credit_limit`
Description	Text, max 100	What the tool does (the AI reads this)	`Returns the customer's credit limit, balance and available credit`

Step 2: Define Parameters

Parameters are child records of the tool. For each parameter, fill in:

Field	Description	Example
Parameter	The input name	`customer_no`
Type	Data type — one of `string`, `number`, `integer`, `boolean`	`string`
Description	What this parameter represents	`The customer number to check`
TestValue	A sample value used when testing the tool	`C10000`

Note: There is no "Required" field. All custom-tool parameters are always emitted as required — the AI is expected to supply every parameter you define. The available types are exactly string, number, integer, and boolean.

Step 3: Implement the Tool

The tool's logic is an AL script stored with the tool. To edit it:

On the Tool Designer Card, choose the Edit Tool Code action — this opens the Script Editor page.
Write your AL script. The script is compiled and executed at runtime by the AL Compiler and Interpreter dependency.

Inside the script:

The parameters you defined are available by name.
The current data-context record is exposed as a global named Rec.
Call setcontext() to set a new current data context (for example, after locating or creating a record) so that follow-up tools act on it.
The text your script produces is returned to the AI as the tool result.

Example Implementation

An AL script for a check_credit_limit tool. It uses the customer_no parameter to look up a customer and returns a readable result:

var
    Customer: Record Customer;
    AvailableCredit: Decimal;
begin
    if Customer.Get(customer_no) then begin
        Customer.CalcFields("Balance (LCY)");
        AvailableCredit := Customer."Credit Limit (LCY)" - Customer."Balance (LCY)";
        Message('Customer %1: Credit Limit = %2, Balance = %3, Available = %4',
            customer_no, Customer."Credit Limit (LCY)", Customer."Balance (LCY)", AvailableCredit);
    end else
        Message('Customer %1 not found', customer_no);
end;

If the tool should leave a record in context for subsequent tools to work on, call setcontext() with that record.

Tool Design Best Practices

Naming Conventions

Use lowercase with underscores: check_credit_limit, get_vendor_info
Use verb-first naming: create_, get_, update_, check_, calculate_
Be specific: get_customer_balance is better than get_data

Writing Descriptions

The tool description is critical — it is what the AI reads to decide when to use the tool. Good descriptions:

Start with a clear action verb: "Checks...", "Creates...", "Returns..."
Explain what the tool returns, not just what it does
Mention when the tool should (or should not) be used
Include any important constraints or limitations

Good: "Checks if a customer's outstanding balance exceeds their credit limit. Returns the credit limit, current balance, and available credit amount. Use this before creating sales orders to verify the customer can accept new charges."

Bad: "Credit check tool"

Parameter Definitions

Use descriptive parameter names: customer_no not param1
Provide clear descriptions for each parameter — the AI relies on them to supply good values
Remember that every parameter you define is required, so avoid defining parameters the tool can do without
Use appropriate types (string, number, integer, boolean)

Return Values

Return structured, readable text that the AI can parse
Include relevant context in the result
For errors, return a clear error message
For success, include the key data points the AI needs

Managing Custom Tools

Editing a Tool

Select the tool in the Tool List
Modify the name, description, or parameters
Changes take effect on the next workload processing

Deleting a Tool

Select the tool in the Tool List
Delete the tool
The tool — along with its parameters and AL script — is removed from the agent's tool catalog

Testing Custom Tools

Create an agent with Use Tools enabled
Give the agent instructions that should trigger your custom tool
Process a test workload
Check the process activity log for the tool call and its result
Verify the Tool Used field shows your custom tool name

Tool Registration

Custom tools are registered dynamically when the AI request is built:

The system reads all tool definitions from the Tool Designer table
Each tool is formatted as a JSON function definition
The definitions are included in the AI provider request
The AI model sees both built-in and custom tools equally

This means custom tools are available to all agents with Use Tools enabled — there is no per-agent tool filtering.

Tips and Best Practices

Start with a few focused, well-tested custom tools rather than many broad ones
Test tools with the interactive chat before using them in production workloads
Keep tool descriptions accurate — if the AI misuses a tool, the description may need refining
Monitor tool usage in process activity logs to see if agents are calling tools as expected
Consider the security implications of tools that modify data
Document your custom tools for other team members who design agents