> For the complete documentation index, see [llms.txt](https://help.sipgate.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.sipgate.com/documentation/en/connections-and-integrations/live-call-funktionen.md).

# Live call functions

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.

{% hint style="info" %}
**Prerequisite:** You need an accessible MCP server.
{% endhint %}

***

### Step 1: Add MCP server

<figure><img src="/files/9bbf8bf83c5673643ea9d84b4b84a9399dc7f6cb" alt=""><figcaption></figcaption></figure>

1. Open the desired AI agent in app.sipgate.com.
2. Switch to the tab **Integrations**.
3. In the section **Live call functions** 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 on **Save**. sipgate automatically connects to the server and checks the connection.

{% hint style="warning" %}
**Attention:** The URL must start with `https://` . Connections without TLS are not accepted.
{% endhint %}

***

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

{% hint style="info" %}
**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.
{% endhint %}

***

### Step 3: Integrate MCP server into your [playbook](/documentation/en/behavior/playbooks.md#wie-funktionieren-playbooks) integrate

<figure><img src="/files/0d54ecf6a7f2b1efeb122c796204fc37e91d94d2" alt=""><figcaption></figcaption></figure>

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.

{% hint style="warning" %}
**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.
{% endhint %}

{% hint style="success" %}
**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.
{% endhint %}

***

### Example: [playbook](/documentation/en/behavior/playbooks.md#wie-funktionieren-playbooks)- Structure for an appointment booking

**Playbook condition:** If the user wants to book an appointment or asks about available appointments.

<table><thead><tr><th width="46.76995849609375">#</th><th width="168.4600830078125">Task name</th><th width="416.78045654296875">Description</th><th align="center">Summary</th></tr></thead><tbody><tr><td>1</td><td><strong>Ask for time of day</strong></td><td>Ask the user which part of the day they prefer for the appointment. The four options are: <code>morning</code>, <code>noon</code>, <code>afternoon</code> or <code>evening</code>. Remember the answer as <code>preferred_timeslot</code> for all further tool calls.</td><td align="center">✅</td></tr><tr><td>2</td><td><strong>Get appointment suggestions</strong></td><td>Call <code>get_next_suggestions</code> with the remembered <code>preferred_timeslot</code> Present the returned appointment suggestions with date and time to the user.</td><td align="center">❌</td></tr><tr><td>3</td><td><strong>Confirm slot or alternative</strong></td><td>Ask the user: Does one of the suggestions fit? Would they like to specify a particular day? Or does none of the suggestions fit?<br>• Slot chosen → remember appointment, continue to task 5 (collect first name)<br>• Specific day → continue to task 4 (ask for day &#x26; daily suggestions)<br>• None fit → back to task 2 (get appointment suggestions)</td><td align="center">✅</td></tr><tr><td>4</td><td><strong>Ask for day &#x26; daily suggestions</strong></td><td>Ask for the desired date. Call <code>get_suggestions_for_day</code> and present the suggestions. Return to the logic of task 3.<br><br><strong>Error handling:</strong><br>• invalid date format → Explain to the user that the date was not recognized, and ask again for a valid date (format: DD.MM.YYYY)<br>• 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<br>• 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</td><td align="center">❌</td></tr><tr><td>5</td><td><strong>Collect first name</strong></td><td>IF the first name is not yet known: ask specifically for it. IF already known: skip this task.</td><td align="center">✅</td></tr><tr><td>6</td><td><strong>Collect last name</strong></td><td>IF the last name is not yet known: ask specifically for it. IF already known: skip this task.</td><td align="center">✅</td></tr><tr><td>7</td><td><strong>Collect phone number</strong></td><td>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.</td><td align="center">✅</td></tr><tr><td>8</td><td><strong>Confirm contact details</strong></td><td>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.</td><td align="center">❌</td></tr><tr><td>9</td><td><strong>Book appointment</strong></td><td>Call <code>book_appointment</code> with the appointment data (start, end) and the contact details (firstname, lastname, phone). IF booking successful (<code>success: true</code>): Confirm the booking with date and time and continue with task 10 (thank you &#x26; say goodbye).<br><br><strong>Error handling:</strong><br>• 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)<br>• 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</td><td align="center">✅</td></tr><tr><td>10</td><td><strong>Thank you &#x26; say goodbye</strong></td><td>Thank the user for the conversation and wish them a nice day. Do not make any further offers.</td><td align="center">❌</td></tr></tbody></table>

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.sipgate.com/documentation/en/connections-and-integrations/live-call-funktionen.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.