> ## Documentation Index > Fetch the complete documentation index at: https://docs.ouraicalling.com/llms.txt > Use this file to discover all available pages before exploring further. # Integrierte Tools > Konfiguriere zuverlässige Aktionen während des Anrufs: Anrufe beenden oder weiterleiten, SMS oder E-Mails senden, Geschäftszeiten prüfen und einen bestätigten Rückruf planen Integrierte Tools sind vorgefertigte Aktionen, die der Assistent während eines laufenden Gesprächs aufrufen kann. Anders als ein Flow brauchen sie keinen Graphen – erstelle ein wiederverwendbares Workspace-Tool, beschreibe, *wann* es laufen soll, und weise es einem oder mehreren Assistenten zu. Sie sind ein **zusätzlicher zweiter Pfad** neben [Flow-Nodes](/flow-builder/overview). Jedes integrierte Tool ist defensiv gebaut: Ein falsch konfiguriertes Tool protokolliert ein `builtin_tool_error`-Anrufereignis, und der Assistent spricht einfach weiter mit dem Anrufer – ein kaputtes Tool bringt nie den ganzen Anruf zum Absturz. Bei **Messaging** (Telegram, Slack, Messenger, Teams, Discord, Google Chat, X) und automatischen **E-Mail**-Antworten laufen dieselben textsicheren integrierten Tools im Next.js-Antwortpfad (auch API/MCP/Wissensdatenbank/Kalender). Reine Sprach-Tools (`end_call`, Weiterleitungen, DTMF/Tastenfeld, Zahlungskarte) sind dort nicht registriert. ## Die eigenständigen Tools | Tool | Was es macht | | --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Anruf beenden** (`end_call`) | Legt auf, nachdem der Assistent seine Aufgabe erledigt und sich verabschiedet hat. | | **Anrufweiterleitung** (`call_transfer`) | Kalte Weiterleitung (SIP REFER) an eine Telefonnummer. | | **Warme Anrufweiterleitung** (`warm_call_transfer`) | Stellt den Anrufer in die Warteschleife, ruft einen Kollegen an, gibt ihm ein kurzes Briefing und führt dann beide zusammen. | | **Übergabe an Assistent** (`assistant_transfer`) | Übergibt den laufenden Anruf an einen anderen KI-Assistenten im selben Workspace (KI→KI). | | **SMS senden** (`send_sms`) | Der Assistent schreibt während des Anrufs eine Textnachricht und verschickt sie – an den Anrufer oder eine feste Nummer. | | **E-Mail senden** (`send_email`) | Der Assistent verfasst und verschickt während des Anrufs eine E-Mail. | | **Geschäftszeiten** (`check_business_hours`) | Lässt den Assistenten prüfen, ob du gerade geöffnet hast – ausgewertet in der Zeitzone des Assistenten. | | **Rückruf planen** (`schedule_callback`) | Der Assistent vereinbart mit dem Anrufer einen Termin; ein Cron-Job wählt den Rückruf später automatisch. Alle Buchungen erscheinen live unter **Zielgruppe → Geplante Rückrufe** (Sprache, Chat/Messaging und E-Mail). | | **Zahlungskarte erfassen** (`collect_payment_card`) | Aktiviert Zahlungskarte-Collect-Nodes in Flows. Karten werden in deinem Stripe-Konto tokenisiert (mit deinem Secret Key). | | **Anrufvariable setzen** (`set_variable`) | Speichert während des Anrufs einen Wert (z. B. den Firmennamen). Das Modell erfährt ihn über das Tool-Ergebnis; spätere Tools, E-Mails, Flow-Bedingungen und Webhooks können ihn dann nutzen. | Die Tastenfeld-Erfassung ist an den Flow gebunden: Füge dazu einen **Collect**-Node im [Flow Builder](/flow-builder/overview) hinzu – dort kann der Worker den DTMF-Status und die Übergänge sicher selbst verwalten. Kalenderaktionen kommen von den [Integrationen](/assistants/calendar-booking). Die alten eigenständigen Konfigurationen `dtmf_input`, `collect_keypad` und `calendar_integration` bleiben nur zur abwärtskompatiblen Anzeige erhalten und können nicht mehr als neue, wiederverwendbare Tools angelegt werden. ## Ein Tool aktivieren Öffne **Tools**, erstelle ein **integriertes** Tool, fülle die Felder aus und weise es einem Assistenten zu. Der erforderliche **Name** ist der exakte Funktionsname, der dem Modell zur Verfügung steht, während die **Beschreibung** dem Modell sagt, wann es das Tool nutzen soll. Aufrufe werden in der Runs-Ansicht dem wiederverwendbaren Tool zugeordnet. ### Anruf beenden Keine weitere Konfiguration außer der Beschreibung. Das Modell muss die Anfrage erst abschließen und sich verabschieden, bevor es die Funktion aufruft; der Worker markiert den Anruf danach als beendet und legt auf. ### Anrufweiterleitung (kalt) * **Telefonnummer** – das feste Ziel. * **KI kann die Zielnummer dynamisch bestimmen** – macht das Ziel stattdessen zu einem Funktionsargument. * **Warm-Transfer-Nachricht** – optionale, nicht unterbrechbare Ansage vor der kalten Weiterleitung. ### Warme Anrufweiterleitung Stellt den Anrufer in die Warteschleife und ruft zuerst einen Kollegen an: * **Supervisor-Telefon** – wer angerufen wird; dabei wird der konfigurierte ausgehende Trunk des Workspace genutzt. * **Wartemusik** – an oder aus, plus eine optionale gesprochene **Wartenachricht**. * **Briefing** – **Zusammenfassungs-Anweisungen** (wie der Anruf für den Kollegen zusammengefasst wird) und ein **Briefing-Opener**, der dem Kollegen vorgesprochen wird; beide unterstützen `{{variables}}`. * **Klingel-Timeout** und **Fallback** – das Gespräch fortsetzen, beenden oder kalt weiterleiten, falls der Rückfrageanruf fehlschlägt. ### Übergabe an Assistent (KI→KI) Übergibt die laufende Sitzung an einen anderen Assistenten im **selben Workspace**, ohne aufzulegen: * **Zielassistent** (`assistant_id`) – erforderlich; muss zum Workspace gehören. * **Nachricht vor der Übergabe** – optionale, nicht unterbrechbare Zeile, die vor der Übergabe gesprochen wird. * **Übergabe-Begrüßung sprechen** – wenn aktiv (Standard), läuft nach dem Wechsel die erste Nachricht bzw. Begrüßung des Zielassistenten. * **Beschreibung** – erforderlich: Sag dem Modell, *wann* es übergeben soll (z. B. Preisfragen → Vertriebsassistent). Das Modell kann einen kurzen `reason` und eine `conversation_summary` mitgeben, damit der übernehmende Assistent den Kontext behält. Der Worker baut STT/LLM/TTS (oder Realtime) für das Ziel neu auf, ruft `session.update_agent` auf und schreibt die Anrufereignisse `assistant_transfer` bzw. `assistant_transfer_failed`. Ein Anruf kann maximal **drei** Mal übergeben werden (Schutz vor Endlosschleifen). Eine Übergabe an denselben Assistenten wird abgelehnt. ### SMS senden Der Assistent formuliert den Text selbst aus dem Gesprächsverlauf und verschickt ihn während des Anrufs: * **Empfänger** (`sms_to_mode`) – `caller` (Standard: die eigene Nummer des Anrufers) oder `custom` mit einer festen **benutzerdefinierten Nummer** (`sms_custom_number`, E.164, z. B. `+491701234567`). Typischer Einsatz: eine Bestätigung, eine Adresse oder einen Zahlungslink per SMS schicken, während das Telefonat noch läuft. ### E-Mail senden Das E-Mail-Tool trennt Empfängererfassung, Absenderidentität, Inhalt und Signatur, damit jeder Teil dort, wo nötig, deterministisch bleibt: * **Empfänger** (`email_to_mode`) – `ask` nutzt einen eigenen E-Mail-Erfassungs-Workflow, der undeutlich gesprochene Adressen normalisiert und explizit bestätigen lässt; `fixed` verwendet `email_fixed_to`. Fehlerhafte oder aus Sprache erkannte Adressen werden beim Versand nie erraten. * **Absender** (`email_sender_mode`) – `auto` versucht zuerst die verifizierte SendGrid-Adresse des Assistenten, dann Workspace-/Reseller-SMTP und zuletzt die Plattform-Mail. Alternativ wählst du explizit **Workspace-SMTP**, **Plattform-Mail** oder eine verifizierte Adresse aus `GET /api/v1/email-senders`. Eine explizite Auswahl schlägt im Fehlerfall klar fehl, statt stillschweigend auf etwas anderes auszuweichen. * **Anzeigename** (`email_from_name`) – optionale Überschreibung pro Tool. * **Inhalt** (`email_content_mode`) – `llm` lässt das Modell Betreff und Text aus dem Gespräch schreiben; `fixed` verschickt immer den konfigurierten, festen Text; `template` löst `{{call_variables}}` auf und blockiert den Versand, wenn ein Wert fehlt. * **Signatur** (`email_signature_mode`) – Workspace-Standard (mit `{agent_name}` / `{{assistant_name}}`), eine individuelle Signatur pro Tool oder keine. Sie wird einmalig vom Anwendungscode angehängt und nicht vom Modell improvisiert. * **Zustellstatus** – ein erfolgreiches Tool-Ergebnis heißt nur, dass der SMTP-Anbieter die Nachricht angenommen hat – nicht, dass sie im Posteingang angekommen ist. Bekannte SendGrid-Bounces, -Blocks und -Spam-Sperren werden vor dem Versand geprüft und dem Assistenten als Zustellfehler zurückgemeldet. Der unumkehrbare Versand deaktiviert Unterbrechungen, überträgt die Anruf-ID in den E-Mail-Verlauf und nutzt einen Idempotenzschlüssel, damit ein wiederholter Funktionsaufruf nicht versehentlich eine zweite Nachricht erzeugt. ### Geschäftszeiten Lässt den Assistenten ehrlich beantworten, wenn jemand fragt „Habt ihr gerade geöffnet?" – und sich außerhalb der Öffnungszeiten entsprechend anders verhalten: * **Geschäftszeiten** (`business_hours`) – ein Wochenplan mit einem oder mehreren Zeitfenstern pro Wochentag (`{"mon": [["09:00", "17:00"]], ...}` – im gleichen Format wie die Anruffenster von Kampagnen). * **Hinweis** (`hours_note`) – ein optionaler Freitext-Hinweis, der zusammen mit dem Ergebnis zurückgegeben wird (z. B. *„An Feiertagen geschlossen"*). Geprüft wird in der **[Zeitzone](/assistants/timezone) des Assistenten** (die Zeitzone einer Kampagne überschreibt sie pro Anruf) – „geöffnet" heißt also immer *lokal* geöffnet. ### Rückruf planen Der Assistent vereinbart mit dem Anrufer einen Rückruftermin; die Plattform speichert ihn, und ein Cron-Job wählt den Rückruf automatisch, sobald er fällig ist: * **Rückrufnummer** (`callback_to_mode`) – `caller` (Standard: den Anrufer unter seiner eigenen Nummer zurückrufen) oder `custom` mit einer festen **benutzerdefinierten Nummer** (`callback_custom_number`, E.164). * **Max. Tage im Voraus** (`max_days_ahead`) – wie weit in der Zukunft ein Rückruf gebucht werden darf (1–365 Tage). Zur Laufzeit verlangt die Funktion eine exakte ISO-8601-Zeit und ein positives Bestätigungs-Flag. Vergangene Termine und Termine jenseits des konfigurierten Limits werden abgelehnt; der Worker setzt niemals stillschweigend 30 Minuten als Standard an oder korrigiert die Wahl des Anrufers eigenmächtig. ### Zahlungskarte erfassen Aktiviert **Zahlungskarte**-Collect-Nodes im [Flow Builder](/flow-builder/nodes). Das ist keine vom LLM aufrufbare Aktion – sie schaltet den Flow-Node frei und legt fest, welches Stripe-Konto die Payment Method erhält. 1. Hinterlege deinen Stripe Secret Key unter **Tools → App Store → Stripe**. 2. Erstelle ein integriertes Tool vom Typ `collect_payment_card` und wähle das Stripe-Konto (`stripe_connection_id`) aus. 3. Weise das Tool einem Assistenten zu. 4. Füge im Flow einen Collect-Node vom Typ **Zahlungskarte** hinzu. Während des Anrufs erfasst der Agent die Kartendaten sicher; die Plattform legt mit deinem Secret Key eine Stripe Payment Method in **deinem** Stripe-Konto an. Gespeichert werden nur `card_last4`, `card_brand` und `stripe_payment_method_id` – niemals die vollständige Kartennummer oder der CVV. Setzt das Plan-Feature **Zahlungskarten erfassen** voraus. Wird pro erfolgreicher Erfassung abgerechnet (siehe Credit-Einstellungen). Ohne verbundenen Stripe Secret Key zeigt das Tool-Formular einen Hinweis, zuerst einen zu hinterlegen – für Kartendaten von Kunden gibt es keinen Plattform-Fallback. ### Anrufvariable setzen Lässt den Assistenten während des Anrufs einen Wert speichern (zum Beispiel den Firmennamen des Anrufers), damit spätere Tools, E-Mails, Flow-Bedingungen und der Post-Call-Webhook ihn nutzen können: * **Erlaubte Keys** (`allowed_keys`) – optionale Allowlist im snake\_case-Format. Leer = jeder gültige Key außer den reservierten Plattform-Keys (`assistant_name`, `direction`, `call_id`, `date`, `time`, `datetime`, `weekday`). * **Beschreibung** – sag dem Modell, *wann* gespeichert werden soll (z. B. nachdem der Anrufer sein Unternehmen genannt hat). Das Tool schreibt in die Variablen-Map des laufenden Anrufs und gibt `{"updated":{"key":"value"}}` zurück, damit das Modell den gespeicherten Wert über das Tool-Ergebnis erfährt. Es schreibt den System-Prompt **nicht** mitten im Anruf um (Realtime-Modelle würden das ohnehin ignorieren). Ein leerer String löscht einen Key. ## System-Tool: get\_current\_time Unabhängig von den konfigurierbaren Tools oben hat jeder Assistent immer das System-Tool **`get_current_time`** – ohne Konfiguration, und es lässt sich nicht deaktivieren. Das Modell ruft es auf, sobald das aktuelle Datum oder die Uhrzeit relevant ist (etwa um *„morgen um 3"* aufzulösen, eine Frist zu prüfen oder einen Termin zu buchen). Die zurückgegebene Zeit ist auf die **Zeitzone** des Assistenten lokalisiert (`assistants.timezone`, ein IANA-Bezeichner wie `Europe/Berlin`). Bei Kampagnenanrufen überschreibt die **Zeitzone der Kampagne** sie pro Anruf (`meta.timezone ?? assistant.timezone`) – siehe [Zeitzone](/assistants/timezone). ## API & MCP Integrierte Tools liegen im `builtin_tools`-Array des Assistenten (aus Kompatibilitätsgründen wird auch `tools` akzeptiert). Setze sie über die öffentliche API: ```bash theme={null} curl -X PATCH https://app.famulor.io/api/v1/assistants/{id} \ -H "Authorization: Bearer $API_KEY" \ -H "Content-Type: application/json" \ -d '{ "tools": [ { "type": "end_call", "description": "Hang up politely once the caller is done." }, { "type": "send_email", "email_to_mode": "ask", "email_sender_mode": "auto", "email_content_mode": "llm", "email_signature_mode": "workspace" } ] }' ``` Denselben Feldvertrag nutzen der Editor, die REST-API und MCP. `GET /api/v1/email-senders` und das MCP-Tool `list_email_senders` legen den secrets-freien Absenderkatalog offen; siehe die [API-Referenz](/api-reference/introduction).