AI Agent Tools: Configuration & Implementation Guide

A tool is a function or API that an agent or workflow can call to perform actions, like accessing databases or manipulating data. Syllable provides default system tools that are already built and ready for you to use out of the box. The tools list page shows all of the tools currently available to your organization with 2 tabs:

Tools: Agent tools are APIs that an agent can use, such as schedule an appointment on behalf of your user, request a prescription refill, or other countless other tasks.
Services: Services are authentication credentials that multiple tool can use.

Agent tools

If you want an agent to reference a specific tool during sessions with users, then you need to provide those instructions in the prompt. For example, if you want to provide hangup instructions to your agent, it might look something like:

Before a call ends, make sure to always ask user whether they need anything else. If user doesn’t need anything else, use “hangup” tool.

Creating an agent tool

To create an agent tool, click the “New tool” button on the top right of the list screen.

Name: The name of the tool is used to reference it elsewhere in Console, including in prompts and agents, so you should pick something that’s easily identifiable. It shouldn’t contain any whitespace.
Service: A service is a grouping of tools. You can select any available service here to add your new tool to that service.

Agent tool schema

You define the behavior and capabilities of a tool using the Tool Schema. More details on the structure of the schema are available here. An example schema to call the Open-Meteo API to look up weather information is below. (Note that the value of the “parameters” field must be defined as a JSON Schema per the OpenAI API.)

{
  "type": "endpoint",
  "endpoint": {
    "url": "https://api.open-meteo.com/v1/forecast",
    "method": "get",
    "argumentLocation": "query"
  },
  "tool": {
    "type": "function",
    "function": {
      "name": "get_weather",
      "description": "Get the weather for a city",
      "parameters": {
        "type": "object",
        "properties": {
          "longitude": {
            "type": "number",
            "description": "The longitude of the city"
          },
          "latitude": {
            "type": "number",
            "description": "The latitude of the city"
          }
        },
        "required": [
          "longitude",
          "latitude"
        ]
      }
    }
  },
  "staticParameters": [
    {
      "name": "current",
      "description": "Information to retrieve from the Open-Meteo API, comma-separated",
      "required": true,
      "type": "string",
      "default": "temperature_2m,relative_humidity_2m,precipitation,rain,showers,snowfall"
    }
  ]
}

The “endpoint” object gives the agent details on what API endpoint to call and how to pass the parameters (in the body of a POST request).
The “tool” object includes a description of the tool, which should be written as instructions to the agent regarding what the tool does. It also includes a “parameters” object, which describes the various parameters that the agent should gather from the user’s input and send to the API endpoint in the “endpoint” object. (In this case, if the user says, for example, “What is the weather in New York City?”, the agent can determine the relevant latitude and longitude from the city name.)
The “staticParameters” object also describes parameters that should be sent to the API, but are predetermined at configuration time, rather than gathered by the agent from the user’s input. They can be configured here at the tool level, but can also be overridden at the agent level, so that different agents can use the same tool (by using a prompt that has been linked to that tool), but specify different behavior for that tool. For more information, see the Tool Configuration section.

Note that the name of each parameter (both static and non-static) in the tool definition must match the name of the parameter on the API endpoint side.

Using Variables in Tools

Variables can enhance your tools by making descriptions more contextual and setting dynamic default values in static parameters. Variable usage in tool descriptions:

{
  "tool": {
    "type": "function",
    "function": {
      "name": "schedule_appointment",
      "description": "Schedule an appointment for {{ vars.customer_name }} at {{ vars.location_name }}. Session: {{ vars.session.id }}"
    }
  }
}

Variable usage in static parameters:

{
  "staticParameters": [
    {
      "name": "customer_id",
      "description": "Customer account identifier",
      "default": "{{ vars.account_id }}",
      "type": "string"
    },
    {
      "name": "timestamp",
      "description": "Current session timestamp", 
      "default": "{{ vars.session.datetime }}",
      "type": "string"
    }
  ]
}

Benefits of variables in tools:

Dynamic defaults: Set contextual default values that change per session
Personalized descriptions: Make tool descriptions more relevant to the current interaction
Session tracking: Include session or user context in tool parameters

For complete variable syntax, available variables, and best practices, see Variables. The “parameters” field is always required. To define a tool that has no parameters, you need to declare an empty “properties” object, like this:

{
  "type": "endpoint",
  "endpoint": {
    "url": "https://official-joke-api.appspot.com/random_joke",
    "method": "get",
    "argument_location": "query"
  },
  "tool": {
    "type": "function",
    "function": {
      "name": "random_joke",
      "description": "Generate a random joke.",
      "parameters": {
        "type": "object",
        "properties": {}
      }
    }
  }
}

Services

Services are a centralized place to store authentication credentials to be used by multiple tools. This way, authentication will only need to be configured once and multiple tools can reuse the same service for authentication within a session.

Creating a service

To create a service, click “New service”.

Name: Name of the service
Description (optional): Description of the service
Auth type (optional): Authentication type

If you are creating a service for authentication, you have 3 options:

Basic: This type of authentication requires username and password.
Bearer: This type of authentication requires a token.
Custom headers: This type of authentication allows multiple custom headers with unique key value pairs.

Note: Once saved, all secret passwords, tokens, authentication credentials are masked for extra security. Syllable does not store these credentials in our system.

You will not be able to view these credentials in the platform because we do not save or store them.
You cannot generate new credentials in our system, you must generate them yourself in your third-party system and remember to copy paste them back in.

Basic authentication Requires username and password.

Bearer authentication Requires token.

Custom headers Allows multiple custom headers. Each auth header must be a unique name.

Once your service is created, you can go to a tool and add them as an authentication service.

System tools

The Syllable platform provides system tools already built and ready for you to use out-of-the-box. System agent tools:

check_voicemail: Detects if a voicemail or a person is picking up the phone.
hangup: Hangs up on the caller.
transfer: Transfers a call to a phone number.
web_search: Looks up information from a website.
dtmf: Enables DTMF input.

System insight tools:

summary-tool: Summarizes and assigns a rating for a session.

System service:

default-v1: Default service categorization to group tools within an organization.

Step tools

A Step Tool (a specific kind of Tool) enables taking long, structured, form-filling instructions from an agent’s prompt and offloading it into a dedicated tool. Now, the agent has a more simplified, streamlined, cheaper prompt that can just call a structured, multi-step workflow tool when needed. By utilizing progressive disclosure and logic, the tool exposes only the context relevant to the active step to the agent, which minimizes agent cognitive load, sharpens task focus, and renders complex workflows significantly more testable and maintainable.

Important Note: Step tools utilize the LLM configurations of the prompt and agent currently calling the tool to process instructions and goals.

Definitions

A step is one “stage” of the workflow being defined as part of the tool.
A transition is the UI connection between two steps.

Important Logic Rules Before building, keep these structural constraints in mind:

Steps First: It’s useful to have a plan of how many steps the tool will require, and create all the steps first.
Solo Steps: You can create standalone steps that do not transition to any other step.
Connected Transitions: However, you cannot transition to a step that does not yet exist. You must first create the destination step, then go to the origin step and transition to it. (e.g., If I have Step A. I must first create Step B. Then go to the transition section in Step A and select Step B.)

Creating a Step Tool To create a tool, go to Tools and click “New tool” in the top right. Select “Steps”.

To start, you must fill in the details of the step tool.

Name (Required): The name of the step tool. Must be unique, and contain no spaces.
Description (Required): The description of the tool.
Service (Required): The associated service for the tool.

Once you click “Create”, the process to create a step tool is started. However, if you exit without clicking “Save”, the tool will not be created and you will lose your changes.

Anatomy of a Step Tool

There are two ways to configure your step tool and also, two ways to visualize the same information. The diagram on the right will update when you “Apply changes”, regardless of which method you use.

Form: For users who prefer being guided through form field UI, in a more user-friendly way, you can fill in form fields in the Form tab. This provides guidelines on conditional logic and as long as you fill in the required fields, it should pass all validation errors.
JSON: For users who prefer high-level control and have familiarity with JSON, you can just copy-paste configurations from other tools. And then resolve validation errors.
1. Import/Export: You can paste raw JSON to generate the tool instantly.
2. Validation: You must save changes to validate the JSON against the required schema.

Each step contains four sections: 1) Step details

Name: The name of the step to be referred to in transitions.
Goal: The specific outcome this step is trying to achieve.
Instructions: Specific prompts sent to the LLM to guide it through this specific step, including any relevant tool calls..

2) Inputs

Inputs act as variables for the step. You can add multiple inputs to capture specific data points.

Name: Name of the input, used to reference the value in later conditions (e.g., answered_relationship).
Type (optional): Type of input, supports string, boolean, integer (whole numbers), and number.
Required checkbox: Checkbox for whether step can be completed without this input data.
Description (optional): Description of the input

For string type inputs, there are conditional fields that also appear: enum values, format, pattern (regex).

3) Events & Actions

Events trigger logic at specific lifecycle stages: Enter, Presubmit, and Submit.
Based on the event, different actions are supported. (e.g., “Enter” event doesn’t have the “Save” action, but the “Submit” event does.

Event	When
enter	On entering step, before input collection
presubmit	After submit, before validation
submit	After successful validation

Within each event, you can add Actions. Actions are operations executed in response to events.

Action	Purpose
get	Populate inputs from saved variables
set	Store a value to a variable
inc	Increment a numeric counter
save	Persist collected inputs to variables
say	Inject a scripted message into conversation
call	Trigger a tool call without waiting for LLM

Actions by Event

	enter	presubmit	submit
get	✓	✓	-
set	✓	✓	✓
inc	✓	✓	✓
save	-	✓	✓
say	✓	-	✓
call	✓	-	✓

4) Transitions Transitions are the lines connecting your boxes. They define the “path” through the tool.

Branching Types: Supports only-If, If-Else, and only-Else transitions.
Note: You can only have one only-Else transition per Step.
Tip: Recommend creating all steps needed first, then start linking each step through transitions. To link Step A to Step B, you must create Step B first.

Apply changes vs Save You may have noticed, there is an “Apply changes” and a “Save”. What is the difference? “Apply changes” refreshes the diagram without actually saving and submitting the tool. This allows you to make adjustments and edits to step names, transitions, etc. without having to resolve all validation errors. If you exit the tool, you will lose your changes. “Save” is when you’re ready to save the step tool. This will run all validation checks and you will not be able to save until you’ve fixed any errors.

Action	What it does	When to use it	Changes saved?
Apply Changes	Refreshes the diagram, and does a quick, local validation check for correct formatting.	Use this to see your new Step names or transitions visually without committing.	No, if you exit the tool, and have only “Applied changes”, you will lose your unsaved work. Make sure you click “Save” before you exit the page.
Save	Submits the configuration and runs full validation checks.	Use this when you are finished or want to check for logic/schema errors.	Yes, if you exit the tool, after clicking “Save”, your work is saved.

Because you cannot refresh the diagram without applying changes, there are a few things to note:

Cannot switch JSON/Form tabs while editing: If you are working in the JSON tab and want to switch to the Form tab, you will need to first “Apply changes” and “Save” before switching modes.
Cannot add step while editing: If you are currently editing a step and haven’t saved or applied your changes, you will not be able to add a new step. You must first “Apply changes” or “Save” before adding a new step.

Viewing a step tool

After saving, you can view the step tool, without needing to edit it.

To edit, click the Edit button.
To delete, select the 3-dot more icon and select Delete. You cannot delete if the tool is assigned to a prompt. You must first remove the tool from all prompts before you can delete it.
To duplicate, select the 3-dot icon and select Duplicate. The tool must have a unique name.

Introduction to Syllable

Tutorials

Account

Workspaces

Resources

Tools

Agent tools

Creating an agent tool

Agent tool schema

Using Variables in Tools

Services

Creating a service

System tools

Step tools

2) Inputs

3) Events & Actions

Introduction to Syllable

Tutorials

Account

Workspaces

Resources

​Agent tools

​Creating an agent tool

​Agent tool schema

​Using Variables in Tools

​Services

​Creating a service

​System tools

​Step tools

2) Inputs

3) Events & Actions

Agent tools

Creating an agent tool

Agent tool schema

Using Variables in Tools

Services

Creating a service

System tools

Step tools