Live call functions

With live call functions, your agent can access external systems during an ongoing call.

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 agent is supposed to 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 lie 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

1. Open the overview of the desired AI agent in app.sipgate.com.

2. Click the card of the AI agent and then select Tools from it.

3. In the Live-call functions area, click Add.

4. 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.

5. Click Save. sipgate will automatically connect to the server and check the connection.

Important: The URL must start with https:// . Connections without TLS are not accepted.

---

Step 2: Check the tools of the MCP server

After a successful connection, sipgate displays the tools provided by the server in the overview. Check the following there:

• Tool name: May be at most 28 characters long. Longer names are marked as errors in the overview and can cause the AI agent to not use the tool reliably.

• Tool descriptions: The descriptions are received from the MCP server and adopted. The more precise the description, the better the AI agent can recognize when it should use the tool. If possible, adjust the tool description on the MCP server side.

• Parameters: Each parameter should also have a meaningful description. The information about which format (string, array, etc.) the MCP server expects it in and whether it is optional or required is crucial for a 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, only working days)

• avoids technical implementation details (what happens in the background is irrelevant to the agent)

A bad description is too general or missing entirely. 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 toward goals. 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 . 2. Save the ID. 3. Then call get_name ..."

The AI agent decides for itself which tools it uses and in what order to achieve the goal.

Important: 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: As far as possible, one tool per task

If you reference MCP tools in individual playbook tasks, the following rule of thumb is recommended: as far as possible, use 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: playbookstructure for an appointment booking

Condition for the playbook: If the user wants to book an appointment or asks for available appointments.

#	Task name	Description	Summary
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 to the user with date and time.	❌
3	Confirm slot or alternative	Ask the user: Does one of the suggestions fit? Would they like to name a specific day? Or does none of the suggestions fit? • Slot chosen → save appointment, continue with task 5 (capture first name) • Specific day → continue with 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 bookings can only be made up to 2 months in advance, and ask for a nearer date • other error → Explain the problem and return to task 3 (confirm slot or alternative) so the user can choose another day or request new suggestions	❌
5	Capture first name	IF the first name is not yet known: ask specifically for it. IF it is already known: skip this task.	✅
6	Capture last name	IF the last name is not yet known: ask specifically for it. IF it is already known: skip this task.	✅
7	Capture phone number	The caller's phone number is in the context under “User with the 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 the first name, last name, and phone number once more 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 data (firstname, lastname, phone). IF booking is successful (success: true): Confirm the booking with date and time and continue with task 10 (thank you & goodbye). Error handling: • Slot taken (409 / “no longer available") → Inform the user that the slot has now been taken, 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 try again later	✅
10	Thank you & 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 added new tools, open the overview of the agent's live-call functions under Integrations. There, click Refresh. The current tool list will then be reloaded.

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 provide useful feedback for invalid data?

• Does the agent respond sensibly to the server's error messages?

---

Security notes

When setting up your MCP server, observe the following general technical recommendations. Which protective measures are appropriate depends on the respective use case, the data processed, and the connected systems.

• Access to the MCP server: Define who is allowed to communicate with your MCP server. Public tool calls should only be used for non-sensitive 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 an effect on a system are performed, access should additionally be protected, for example by authentication, security tokens, or other suitable access controls.

• Access rights of the MCP server: Grant only the permissions that the MCP server needs for the respective purpose. For example, if the MCP server is supposed to write data to a third-party system, it should not automatically receive full read and write access to all data in that system. Regularly check whether the permissions granted are still necessary.

• Identity verification: In principle, assume that a caller is not reliably identified at first. Before sensitive data is returned or actions are carried out, the MCP server should verify whether the caller is authorized to do so. Depending on the use case, additional verification features such as a parcel number, a code word, a one-time code, or a password can be used. The transmitted phone number alone should not be used as a reliable identity check.

• Input validation: Validate all inputs 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

Return only data that is required for the current process. The MCP server should be designed so that no information is disclosed to unauthorized callers. Especially for personal or confidential data, check whether the output is necessary for the respective purpose.