Live call functions
With live call features, your AI agent can access external systems during an ongoing conversation.
The connection is made via an MCP server. MCP stands for Model Context Protocol and is a standardized interface through which AI agents can communicate with external services.
When are live call functions useful?
Live call functions are suitable when the AI agent should retrieve current data during the conversation, check inputs, or perform actions in external systems.
Typical examples are:
Retrieve customer data
Check or book appointments
Create tickets
Validate inputs
Calculate rules, e.g. date limits or number formats
Calculations and validations should be handled by the MCP server, not by the AI agent. For example, if a customer number must be exactly 13 digits long or a date must not be in the past, the MCP server should perform this check and return a clear result.
Prerequisite: You need an accessible MCP server.
Step 1: Add MCP server
Open the desired AI agent in app.sipgate.com.
Switch to the tab Integrations.
In the section Live call functions click Add.
Fill out the form:
Name (optional): An internal display name for the server.
URL: The HTTPS address of your MCP server.
Token (optional): An authentication token if your server requires protection.
Click on Save. sipgate automatically connects to the server and checks the connection.
Attention: The URL must start with https:// . Connections without TLS are not accepted.
Step 2: Check MCP server tools
After a successful connection, sipgate displays the tools provided by the server in the overview. Check there:
Tool name: May be at most 28 characters characters long. Longer names are marked as an error in the overview and can cause the AI agent to use the tool unreliably.
Tool descriptions: The descriptions are received from the MCP server and adopted. The more precise the description, the better the AI agent recognizes when to use the tool. If possible, adjust the tool description on the MCP server side.
Parameters: Each parameter should also have a meaningful description. Information on which format (string, array, etc.) the MCP server expects it in and whether it is optional or required is crucial for successful exchange between the agent and the MCP server.
Tip: The description is the most important part of a tool - it is the only thing the agent uses to infer when and how to use the tool.
A good description:
clearly states the purpose of the tool
explains, if applicable, limitations (e.g. maximum 3 results, working days only)
avoids technical implementation details (what happens in the background is irrelevant to the agent)
A bad description is too general or missing altogether. The agent will then use the tool incorrectly or not at all.
Step 3: Integrate MCP server into your playbook integrate
The AI agent works in a goal-oriented way. In the playbook, describe what it should achieve — not how it should proceed step by step.
Good: “Determine the caller's customer number based on their phone number get_customer and greet them by name get_name."
Less good: “1. Call the tool get_customer up. 2. Save the ID. 3. Then call get_name up …"
The AI agent decides for itself which tools it uses and in what order to achieve the goal.
Attention: Business logic, validation, and state management do not belong in the playbook — that is the MCP server's job. The playbook describes goals, the MCP server provides the tools.
Tip: Preferably one tool per task
If you reference MCP tools in individual playbook tasks, the following rule of thumb is recommended: preferably only one tool per task. This improves reliability during the live conversation, because each step corresponds to exactly one purpose and the agent does not have to coordinate parallel tool calls within a task.
Example: playbook- Structure for an appointment booking
Playbook condition: If the user wants to book an appointment or asks about available appointments.
1
Ask for time of day
Ask the user which part of the day they prefer for the appointment. The four options are: morning, noon, afternoon or evening. Remember the answer as preferred_timeslot for all further tool calls.
✅
2
Get appointment suggestions
Call get_next_suggestions with the remembered preferred_timeslot Present the returned appointment suggestions with date and time to the user.
❌
3
Confirm slot or alternative
Ask the user: Does one of the suggestions fit? Would they like to specify a particular day? Or does none of the suggestions fit? • Slot chosen → remember appointment, continue to task 5 (collect first name) • Specific day → continue to task 4 (ask for day & daily suggestions) • None fit → back to task 2 (get appointment suggestions)
✅
4
Ask for day & daily suggestions
Ask for the desired date. Call get_suggestions_for_day and present the suggestions. Return to the logic of task 3.
Error handling:
• invalid date format → Explain to the user that the date was not recognized, and ask again for a valid date (format: DD.MM.YYYY)
• Date too far in the future → Inform the user that booking is only possible up to 2 months in advance, and ask for a closer date
• Other error → Explain the problem and return to task 3 (confirm slot or alternative), so that the user can choose another day or request new suggestions
❌
5
Collect first name
IF the first name is not yet known: ask specifically for it. IF already known: skip this task.
✅
6
Collect last name
IF the last name is not yet known: ask specifically for it. IF already known: skip this task.
✅
7
Collect phone number
The caller's phone number is in the context under “User with phone number: …” — use this directly, DO NOT ask for it. Only if this entry is missing or the caller is anonymous: ask specifically for the phone number.
✅
8
Confirm contact details
Read out first name, last name, and phone number again and ask for confirmation. If the user makes a correction: apply the correction and read the data out again.
❌
9
Book appointment
Call book_appointment with the appointment data (start, end) and the contact details (firstname, lastname, phone). IF booking successful (success: true): Confirm the booking with date and time and continue with task 10 (thank you & say goodbye).
Error handling:
• Slot taken (409 / “no longer available") → Inform the user that the slot has been taken in the meantime, and return to task 2 (get appointment suggestions)
• Other error → Briefly explain to the user that something went wrong, and ask whether they would like to choose another appointment (back to task 3 – confirm slot or alternative) or whether they would like to try again later
✅
10
Thank you & say goodbye
Thank the user for the conversation and wish them a nice day. Do not make any further offers.
❌
Update connection
If you have updated your MCP server, for example by adding new tools, open the Live call functions overview of the agent under Integrations. There click on Refresh. The current list of tools will then be retrieved again.
Test live call functions
Manual test calls are recommended, with the playbook actively used.
Check the following:
Does the agent trigger the right tools?
Are the parameters filled in correctly?
Does the agent reliably ask for missing parameters?
Are inputs validated by the MCP server?
Does the agent give sensible feedback for invalid data?
Does the agent respond appropriately to server error messages?
Security notes
When setting up your MCP server, observe the following general technical recommendations. Which protection measures are appropriate depends on the specific use case, the data processed, and the connected systems.
Access to the MCP server: Define who may communicate with your MCP server. Public tool calls should only be used for non-critical functions, for example simple checks or processes that correspond to a public online form. As soon as personal or sensitive data is returned or actions with effects on a system are performed, access should also be protected, for example by authentication, security tokens, or other suitable access controls.
Access rights of the MCP server: Grant only the permissions the MCP server needs for the respective purpose. If, for example, the MCP server is to write data to a third-party system, it should not automatically receive full read and write access to all data in that system. Check regularly whether the permissions granted are still required.
Identity verification: As a rule, assume that a caller is not reliably identified at first. Before sensitive data is returned or actions are performed, the MCP server should check whether the caller is authorized to do so. Depending on the use case, additional verification features such as a package number, code word, one-time code, or password can be used. The transmitted phone number alone should not be used as reliable identity verification.
Input validation: Validate all inputs on the server side. Do not rely on an AI agent always recognizing or checking values correctly. Formal checks, for example lengths, number formats, required fields, or check digits, should be handled by the MCP server.
Data sharing and data minimization
Only return data that is required for the current process. The MCP server should be designed so that no information is disclosed to unauthorized callers. In particular, when dealing with personal or confidential data, check whether the output is necessary for the respective purpose.
Last updated