TrueDialog MCP

MCP, das Model Context Protocol, ermöglicht einem KI-Client den Zugriff auf die Tools und Daten, die er braucht, um tatsächlich etwas zu tun. tdmcp ist die Verbindung zwischen jedem MCP-fähigen Client und der TrueDialog SMS API: dreißig Jahre Carrier-Infrastruktur, Opt-out-Verarbeitung, Zwei-Wege-Konversationen, RCS, MMS und Short-Code-Verkehr, bereitgestellt über eine kleine Auswahl gut benannter Tools.

Die Authentifizierung erfolgt über OAuth 2.1, nicht über eingefügte Zugangsdaten. Du autorisierst dich einmal in deinem Browser bei auth.tdmcp.com — mit denselben TrueDialog-Anmeldedaten, die du auch für das Portal verwendest. Dein KI-Client hält nur ein kurzlebiges Bearer-Token, niemals dein Passwort, und sendet es bei jedem Aufruf mit. Der Connector validiert das Token und ermittelt serverseitig über einen privaten Back-Channel deinen TrueDialog-Zugriff. In deiner Client-Konfiguration werden keine langlebigen Zugangsdaten gespeichert.

Die Laufzeitumgebung ist bewusst unspektakulär: Azure Container Apps hinter einem verwalteten Front Door, AMD64-Container, FastMCP mit Streamable HTTP, keine Sticky Sessions. Terraform für alles. Nichts Überraschendes, nichts im kritischen Pfad, was du nicht selbst eingerichtet hast.

---

Endpunkt: https://connect.tdmcp.com. Streamable HTTP, zustandslos. Derselbe Transport ist auch unter https://connect.tdmcp.com/mcp erreichbar — ein Kompatibilitätsalias für Clients, die das /mcp-Pfadkonvention erwarten; beide URLs funktionieren. Die Authentifizierung erfolgt über OAuth 2.1 — dein Client erkennt sie automatisch und führt dich durch die Anmeldung im Browser. Es müssen keine Schlüssel oder Header eingefügt werden.

So funktioniert die Autorisierung

Jeder der folgenden Clients durchläuft dieselben vier Schritte, von denen die meisten automatisch ablaufen:

1. Füge connect.tdmcp.com zu deinem Client hinzu.
2. Der Client findet den OAuth-Server unter auth.tdmcp.com und registriert sich automatisch (dynamische Clientregistrierung, PKCE).
3. Ein Browserfenster wird geöffnet. Melde dich mit deinen TrueDialog-Anmeldedaten an.
4. Dein Client erhält ein Token und ist verbunden. Er erneuert es automatisch — du musst dich erst wieder anmelden, wenn die Sitzung abläuft.

Öffne in Claude (Desktop-App oder claude.ai) Customize → Connectors und klicke auf + → Add custom connector. Gib einen Namen und die Endpunkt-URL ein:

add custom connector

Name:   TrueDialog
URL:    https://connect.tdmcp.com/

Klicke auf Add und dann auf Connect. Ein Browserfenster wird für die TrueDialog-Anmeldung geöffnet; bestätige sie, und die neun Tools werden angezeigt — Claude registriert sich automatisch beim OAuth-Server, du musst nichts einfügen. Bei Team/Enterprise muss ein Owner die Funktion zuerst für die Organisation aktivieren (Organization settings → Connectors → Add → Custom → Web); danach kann jedes Mitglied sie unter Customize → Connectors hinzufügen.

---

Jedes MCP-Tool ist einer bestimmten TrueDialog-API-Oberfläche zugeordnet. Die Tools sind bewusst klein und eindeutig gehalten; die Schlussfolgerungen zieht der Agent anhand des Prompts, nicht anhand der Tool-Liste. Insgesamt gibt es neun Tools — sechs schreibgeschützte und drei, die Daten ändern.

1. whoami Zeigt den Benutzer und das Konto hinter deiner autorisierten Sitzung an. Nützlich für eine einmalige Authentifizierungsprüfung. Schreibgeschützt.
2. list_accounts Listet alle Konten auf, auf die dein Login zugreifen kann. Für Betreiber mit mehreren Mandanten relevant, für Benutzer mit nur einem Konto nicht. Schreibgeschützt.
3. get_account_info Ruft einen einzelnen Kontodatensatz ab. Standardmäßig wird das authentifizierte Konto verwendet. Schreibgeschützt.
4. list_channels Listet die Kanäle eines Kontos auf — Long Code, Short Code, RCS, E-Mail, Sprache. Rufe das Tool auf, um vor send_sms die Kanal-ID zu ermitteln. Schreibgeschützt.
5. get_contact Sucht einen Kontakt anhand seiner ID. Schreibgeschützt.
6. search_contacts Sucht nach Teilübereinstimmungen in Telefonnummern und E-Mail-Adressen. Schreibgeschützt.
7. create_contact Erstellt einen Kontakt anhand einer Telefonnummer oder E-Mail-Adresse (mindestens eine davon ist erforderlich). Ist die Nummer oder E-Mail-Adresse bereits einem Kontakt zugeordnet, lehnt TrueDialog die Erstellung ab und verweist auf update_contact — es wird nicht stillschweigend ein Duplikat angelegt.
8. update_contact Aktualisiert die Telefonnummer, E-Mail-Adresse oder den Namen eines Kontakts. Das Tool liest zuerst den Datensatz und schreibt nur die übergebenen Felder neu, damit TrueDialogs Update-Funktion, die alle Felder überschreibt, die übrigen Daten nicht löscht — ein Read-Modify-Write-Vorgang, der zusätzlich zur Berechtigung manage auch die Berechtigung contact-read erfordert und bei gleichzeitigen Änderungen nicht atomar ist. Ein Schreibvorgang.
9. send_sms Sendet eine ausgehende SMS an eine oder mehrere Nummern. Ein echter Versand: Standardmäßig wird die Nachricht an echte Mobiltelefone zugestellt (übergib execute=false für einen Testlauf). Löst automatisch einen Versandkanal auf, wenn du keinen angibst. Einwegkommunikation — Antworten werden nicht gelesen.

Sprich mit dem Agenten.

Du rufst diese Tools nicht namentlich auf — du stellst einfach eine Frage, und der Agent wählt die passenden Tools aus. Hier sind ein paar Beispiele zum Ausprobieren, sobald du verbunden bist:

• „Mit welchem Konto bin ich verbunden?“ bestätigt die Authentifizierung
• „Welche Kanäle sind in meinem Konto eingerichtet?“ ruft die Kanäle ab
• „Schick eine SMS an +1 512 555 0142: Ihr Tisch für vier Personen ist für 19 Uhr bestätigt.“ ein Versand, ein Empfänger
• „Finde den Kontakt für 512 555 0142 und teile ihm mit, dass seine Bestellung versandt wurde.“ sucht den Kontakt und sendet eine Nachricht

---

Dateien werden über die E-Mail-Tools übertragen. inbox_send_message und inbox_reply_to_message akzeptieren jeweils eine attachments-Liste; inbox_forward_message übernimmt stattdessen die Originaldateien selbst (include_attachments, standardmäßig aktiviert). Jeder Eintrag in einer attachments-Liste gibt genau eine Quelle für die Bytes an. Welche Quelle du auswählst, entscheidet darüber, ob eine Datei ankommt oder nicht.

Diese Tools gehören zum Inbox-Pack, das pro Deployment aktiviert wird. Der Connector unter connect.tdmcp.com stellt derzeit die neun oben genannten TrueDialog-Tools bereit; Anhänge werden zusammen mit den E-Mail-Tools verfügbar, sobald das Inbox-Pack aktiviert ist.

1. attachment_id Bezeichnet einen Anhang, den die Plattform bereits in einer Nachricht in diesem Posteingang gespeichert hat — die IDs stammen von inbox_get_thread. Der Server hängt die gespeicherten Bytes selbst wieder an, sodass keine Base64-Daten durch das Modell laufen. Das ist die richtige Wahl für alles, was nicht winzig ist, und der naheliegende Weg, wenn die Bytes bereits im Thread vorhanden sind, auf den du antwortest. filename und content_type werden von den gespeicherten Bytes übernommen und können überschrieben werden. Damit entfällt die Transkriptionsgrenze, nicht aber die Größenbeschränkung. (Für Weiterleitungen ist das nicht einmal nötig: inbox_forward_message übernimmt die Originalanhänge standardmäßig.)
2. upload_id Bezeichnet Bytes, die bereits im Speicher abgelegt wurden — der richtige Weg für eine wirklich neue große Datei. POST an /v1/inboxes/{inbox_id}/attachments/uploads mit dem Dateinamen, dem MIME-Typ und der exakten Byte-Länge; PUT die Rohdaten an die zurückgegebene vorab signierte upload_url; gib dann die upload_id beim Senden an. Wenn das Inbox-Pack aktiviert ist, übernimmt inbox_create_attachment_upload den ersten Schritt und gibt upload_id und upload_url zurück. Kein Tool übernimmt PUT, daher kann ein Agent, der nur über diesen Connector Zugriff hat, weiterhin keine neuen Bytes bereitstellen; der Upload muss von einem Client oder einer App erfolgen, die PUT außerhalb des Bandes senden kann.
3. content Base64-Daten inline, zusammen mit filename und content_type. Nur für sehr kleine Dateien zuverlässig — etwa 2 KB oder ungefähr 2.700 Base64-Zeichen —, weil die gesamte Zeichenfolge Zeichen für Zeichen im Tool-Aufruf ausgegeben werden muss und ein einziges falsches Zeichen den Versand mit einem nicht aussagekräftigen Base64-Padding-Fehler scheitern lässt. Das ist eine Zuverlässigkeitsgrenze, keine validierte Beschränkung: Bei 2 KB wird nichts abgelehnt. Der Versand wird angenommen und schlägt später beim Dekodieren fehl.

Serverseitige Beschränkungen

Drei Grenzwerte, die alle serverseitig geprüft werden:

1. 10 MB pro Nachricht, insgesamt über alle Einträge hinweg, unabhängig von ihrer Form — referenzierte Bytes zählen vollständig, genau wie Inline-Daten. Eine Referenz erspart dir das Übertragen einer Datei; sie macht die Datei nicht kleiner.
2. 10 MB pro Datei, angewendet auf die angegebene Größe size_bytes, wenn der Upload-Slot erstellt wird — es wird also nie eine URL ausgegeben, über die ein zu großes Objekt gespeichert werden könnte.
3. 100 Einträge in einer attachments-Liste.

Die Gesamtsumme wird anhand gespeicherter Metadaten geprüft, bevor Bytes abgerufen werden, und erneut, sobald alles aufgelöst wurde. Ein Versand, der den Grenzwert überschreitet, wird daher mit 422 abgelehnt, statt teilweise zugestellt zu werden. Teile eine Menge, die einen der beiden Grenzwerte überschreitet, auf mehrere Sendungen auf.

Die drei Formen lassen sich frei in einer Liste kombinieren. Vorab signierte Upload-URLs sind kurzlebig — standardmäßig 15 Minuten — und der PUT muss exakt den Content-Type und Content-Length senden, die ihm übergeben wurden, da die Signatur beide umfasst. Ein Upload kann nur einmal verwendet werden: Der erste Versand, der darauf verweist, verbraucht ihn. GET …/attachments/uploads/{upload_id} zeigt dir, ob der Slot noch aussteht, wann er abläuft und von welcher Nachricht er verwendet wurde; es prüft nicht, ob dein PUT angekommen ist. Ein Versand, bevor die Bytes vorliegen, wird mit 422 abgelehnt und verbraucht den Upload nicht. Du kannst es also erneut versuchen, sobald der PUT abgeschlossen ist. In umgekehrter Richtung gibt inbox_get_attachment die Bytes eines Anhangs Base64-kodiert zurück.

---

Der MCP-Server ist der Einstieg. Die spannende Produktarbeit baut darauf auf: eine Agentenlaufzeit, die SMS-Konversationen in Ergebnisse verwandelt.

Wenn eine SMS-Antwort eingeht, wecke den passenden Agenten mit dem vollständigen Gesprächskontext auf: der auslösenden ausgehenden Nachricht, dem bisherigen Verlauf des Kunden und dem Ziel des Threads. Webhooks, aber für Agenten.

Verkaufe Ergebnisse, keine Minuten. Mehrstufige Terminbestätigungen und -verschiebungen, vertiefende NPS-Nachfragen bei niedrigen Bewertungen, B2B-Lead-Qualifizierung, Support-Triage. Der Agent führt die Konversation von Anfang bis Ende.

TrueDialogs Compliance-Know-how auf die Antwortebene übertragen. Aus „Schreib mir nachts nicht“ wird ein Angebot für Ruhezeiten statt einer vollständigen Abmeldung. Ein revisionssicherer, TCPA-konformer Prüfpfad ist inklusive.

Ersetze deine Support-Mitarbeiter nicht. Unterstütze sie. Antwortentwürfe, Thread-Zusammenfassungen und Vorschläge für die nächstbeste Aktion — alles direkt in der Agentenkonsole, die sie bereits verwenden.

---

Stack

FastMCP / httpx / Python 3.14
Azure Container Apps / ACR / Static Web Apps / Azure DNS
Terraform / Docker

Lizenz

MIT.

Schriftarten

Lato, JetBrains Mono.