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

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

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

***

### Step 1: Add MCP server

<figure><img src="https://3225157888-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FL8XuEunVQH0eqk0OHmIg%2Fuploads%2Fgit-blob-604371f6f23b278180ff585b698ad8353b044f63%2Fsona-tools.gif?alt=media" alt=""><figcaption></figcaption></figure>

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.

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

***

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

{% 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, 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.
{% endhint %}

***

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

<figure><img src="https://3225157888-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FL8XuEunVQH0eqk0OHmIg%2Fuploads%2Fgit-blob-2499bb5efe06984bf5a2014453cb9ad74e350f43%2Ftools%20in%20playbooks.gif?alt=media" alt=""><figcaption></figcaption></figure>

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.

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

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

***

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

**Condition for the playbook:** If the user wants to book an appointment or asks for 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 to the user with date and time.</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 name a specific day? Or does none of the suggestions fit?<br>• Slot chosen → save appointment, continue with task 5 (capture first name)<br>• Specific day → continue with 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 bookings can only be made up to 2 months in advance, and ask for a nearer date<br>• 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</td><td align="center">❌</td></tr><tr><td>5</td><td><strong>Capture first name</strong></td><td>IF the first name is not yet known: ask specifically for it. IF it is already known: skip this task.</td><td align="center">✅</td></tr><tr><td>6</td><td><strong>Capture last name</strong></td><td>IF the last name is not yet known: ask specifically for it. IF it is already known: skip this task.</td><td align="center">✅</td></tr><tr><td>7</td><td><strong>Capture phone number</strong></td><td>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.</td><td align="center">✅</td></tr><tr><td>8</td><td><strong>Confirm contact details</strong></td><td>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.</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 data (firstname, lastname, phone). IF booking is successful (<code>success: true</code>): Confirm the booking with date and time and continue with task 10 (thank you &#x26; goodbye).<br><br><strong>Error handling:</strong><br>• Slot taken (409 / “no longer available") → Inform the user that the slot has now been taken, 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 try again later</td><td align="center">✅</td></tr><tr><td>10</td><td><strong>Thank you &#x26; 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 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.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.sipgate.de/ai-agents/en/connections-and-integrations/live-call-funktionen.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.