TrueDialog MCP

MCP, le Model Context Protocol, permet à un client IA d’accéder aux outils et aux données dont il a besoin pour agir concrètement. tdmcp assure la liaison entre tout client compatible avec MCP et l’API SMS de TrueDialog : trente ans d’infrastructure opérateur, gestion des désabonnements, conversations bidirectionnelles, RCS, MMS et trafic par numéros courts, le tout exposé sous la forme d’un petit ensemble d’outils bien nommés.

L’authentification repose sur OAuth 2.1, pas sur des identifiants collés dans une configuration. Vous autorisez une fois, dans votre navigateur, auprès de auth.tdmcp.com, en vous connectant avec les mêmes identifiants TrueDialog que pour le portail. Votre client IA ne détient qu’un jeton porteur de courte durée, jamais votre mot de passe, et l’envoie à chaque appel. Le connecteur valide le jeton et résout votre accès TrueDialog côté serveur via un canal privé. Aucune donnée persistante n’est enregistrée dans la configuration de votre client.

Le runtime est volontairement sans surprise : Azure Container Apps derrière une passerelle frontale gérée, conteneurs AMD64, FastMCP qui sert Streamable HTTP, sans sessions persistantes. Terraform pour l’ensemble. Rien d’inattendu, rien dans le chemin critique que vous n’y ayez placé.

---

Point de terminaison : https://connect.tdmcp.com. Streamable HTTP, sans état. Le même transport répond également à https://connect.tdmcp.com/mcp — un alias de compatibilité pour les clients qui supposent la convention de chemin /mcp ; les deux URL fonctionnent. L’authentification repose sur OAuth 2.1 : votre client découvre automatiquement le serveur et vous guide lors de la connexion dans le navigateur. Aucune clé ni aucun en-tête à coller.

Fonctionnement de l’autorisation

Tous les clients ci-dessous suivent les mêmes quatre étapes, dont la plupart se déroulent automatiquement :

1. Vous ajoutez connect.tdmcp.com à votre client.
2. Le client trouve le serveur OAuth sur auth.tdmcp.com et s’enregistre automatiquement (enregistrement dynamique du client, PKCE).
3. Une fenêtre de navigateur s’ouvre. Vous vous connectez avec vos identifiants TrueDialog.
4. Votre client reçoit un jeton et vous êtes connecté. Il le renouvelle automatiquement : vous n’aurez pas à vous reconnecter avant l’expiration de la session.

Dans Claude (application Desktop ou claude.ai), ouvrez Personnaliser → Connecteurs et cliquez sur + → Ajouter un connecteur personnalisé. Donnez-lui un nom et l’URL du point de terminaison :

ajouter un connecteur personnalisé

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

Cliquez sur Ajouter, puis sur Connecter. Une fenêtre de navigateur s’ouvre pour la connexion à TrueDialog ; approuvez-la et les neuf outils apparaissent — Claude s’enregistre automatiquement auprès du serveur OAuth, rien à coller. Avec Team/Enterprise, un propriétaire doit d’abord l’activer pour l’organisation (Paramètres de l’organisation → Connecteurs → Ajouter → Personnalisé → Web) ; ensuite, chaque membre l’ajoute depuis Personnaliser → Connecteurs.

---

Chaque outil MCP correspond à une surface spécifique de l’API TrueDialog. Ils sont volontairement simples et explicites ; le raisonnement de l’agent se trouve dans le prompt, pas dans la liste des outils. Neuf outils au total — six en lecture seule, trois qui écrivent.

1. whoami Retourne l’utilisateur et le compte associés à votre session autorisée. Pratique pour vérifier l’authentification en une seule opération. Lecture seule.
2. list_accounts Répertorie tous les comptes accessibles avec votre identifiant. Utile aux opérateurs multi-locataires, pas aux utilisateurs d’un seul compte. Lecture seule.
3. get_account_info Récupère un enregistrement de compte. Par défaut, celui du compte authentifié. Lecture seule.
4. list_channels Répertorie les canaux — numéros longs, numéros courts, RCS, e-mail, voix — d’un compte. Appelez cet outil pour trouver l’identifiant du canal avant send_sms. Lecture seule.
5. get_contact Recherche un contact par identifiant. Lecture seule.
6. search_contacts Recherche des correspondances partielles dans les numéros de téléphone et les adresses e-mail. Lecture seule.
7. create_contact Crée un contact à partir d’un numéro de téléphone ou d’une adresse e-mail (au moins l’un des deux est requis). Si ce numéro ou cette adresse figure déjà sur un contact, TrueDialog refuse la création et vous oriente vers update_contact — aucun doublon n’est créé silencieusement.
8. update_contact Met à jour le téléphone, l’adresse e-mail ou le nom d’un contact. L’outil lit d’abord l’enregistrement et ne réécrit que les champs que vous fournissez, afin que la mise à jour de TrueDialog, qui écrase tout, n’efface pas le reste — il s’agit d’une opération de lecture-modification-écriture, qui nécessite donc l’autorisation de lecture des contacts en plus de l’autorisation de gestion, et qui n’est pas atomique en cas de modification concurrente. Écriture.
9. send_sms Envoie un SMS sortant à un ou plusieurs numéros. Envoi réel : par défaut, le message est transmis à des téléphones actifs (passez execute=false pour effectuer un test à blanc). Résout automatiquement un canal d’envoi si vous n’en indiquez aucun. À sens unique — ne lit pas les réponses.

Discutez avec lui.

Vous n’appelez pas ces outils par leur nom : il vous suffit de poser une question, et l’agent choisit les bons outils. Voici quelques exemples à essayer une fois connecté :

• « À quel compte suis-je connecté ? » confirme l’authentification
• « Quels canaux sont configurés sur mon compte ? » consulte les canaux
• « Envoie un SMS au +1 512 555 0142 : votre table pour quatre est confirmée pour 19 h. » un envoi, un destinataire
• « Trouve le contact associé au 512 555 0142 et informe-le que sa commande a été expédiée. » recherche + envoi

---

Les fichiers transitent par les outils de messagerie. inbox_send_message et inbox_reply_to_message acceptent chacun une liste de pièces jointes ; inbox_forward_message transporte plutôt les fichiers d’origine lui-même (include_attachments, activé par défaut). Chaque entrée d’une liste de pièces jointes désigne exactement une source de données binaires, et le choix de cette source détermine si le fichier arrive ou non.

Ces outils appartiennent au pack Inbox, activé pour chaque déploiement. Le connecteur sur connect.tdmcp.com annonce actuellement les neuf outils TrueDialog ci-dessus ; les pièces jointes sont disponibles avec les outils de messagerie, partout où le pack Inbox est activé.

1. attachment_id Désigne une pièce jointe déjà stockée par la plateforme, dans un message de cette boîte de réception — les identifiants proviennent de inbox_get_thread. Le serveur rattache lui-même les données stockées, de sorte qu’aucune donnée base64 ne transite par le modèle. C’est la solution pour tout fichier qui n’est pas minuscule, et la voie naturelle lorsque les données figurent déjà dans le fil auquel vous répondez. filename et content_type sont hérités des données stockées et peuvent être remplacés. Cette méthode supprime la limite de transcription, pas la limite de taille. (Les transferts n’en ont même pas besoin : inbox_forward_message transporte les pièces jointes d’origine par défaut.)
2. upload_id Désigne des données déjà préparées dans le stockage — la méthode à utiliser pour un nouveau fichier volumineux. POST vers /v1/inboxes/{inbox_id}/attachments/uploads avec le nom du fichier, son type MIME et sa longueur exacte en octets ; PUT les données brutes vers l’upload_url pré-signée renvoyée ; puis indiquez l’upload_id dans votre envoi. Partout où le pack Inbox est activé, inbox_create_attachment_upload effectue la première étape et renvoie l’upload_id et l’upload_url. Aucun outil ne fait le PUT, donc un agent qui n’a accès qu’à ce connecteur ne peut toujours pas préparer de nouvelles données ; le téléversement doit être effectué par un client ou une application capable de PUT hors bande.
3. content Données base64 intégrées, fournies avec filename et content_type. Fiable uniquement pour les fichiers très petits — environ 2 Ko, soit quelque 2 700 caractères base64 — car la chaîne entière doit être émise caractère par caractère dans l’appel d’outil, et un seul caractère incorrect fait échouer l’envoi avec une erreur de remplissage base64 peu explicite. Il s’agit d’une limite de fiabilité, pas d’une limite validée : rien ne vous arrête à 2 Ko. L’envoi est accepté, puis échoue plus tard, lors du décodage.

Contrôles appliqués par le serveur

Trois limites, toutes vérifiées côté serveur :

1. 10 Mo par message, au total pour toutes les entrées, quelle que soit leur forme — les données référencées sont comptabilisées intégralement, exactement comme les données intégrées. Le référencement vous évite de retranscrire un fichier ; il ne le rend pas plus petit.
2. 10 Mo par fichier, limite appliquée à size_bytes déclaré lors de la création de l’emplacement de téléversement — aucune URL permettant de stocker un objet trop volumineux n’est donc jamais émise.
3. 100 entrées dans une même liste de pièces jointes.

Le total est vérifié à partir des métadonnées stockées avant la récupération des données, puis à nouveau une fois toutes les données résolues ; un envoi dépassant la limite est donc refusé avec un 422, au lieu d’être partiellement transmis. Répartissez sur plusieurs envois tout ensemble qui dépasse l’une ou l’autre limite.

Les trois formes peuvent être mélangées librement dans une même liste. Les URL de téléversement pré-signées sont de courte durée — 15 minutes par défaut — et le PUT doit envoyer exactement le Content-Type et le Content-Length qui lui ont été fournis, car la signature couvre les deux. Un téléversement est à usage unique : le premier envoi qui le référence le consomme. GET …/attachments/uploads/{upload_id} vous indique si l’emplacement est toujours en attente, quand il expire et quel message l’a consommé ; il ne vérifie pas que votre PUT est arrivé. Un envoi effectué avant l’arrivée des données est refusé avec un 422 et ne consomme pas le téléversement ; vous pouvez donc réessayer une fois que le PUT est terminé. Dans l’autre sens, inbox_get_attachment renvoie les données d’une pièce jointe encodées en base64.

---

Le serveur MCP est le point d’entrée. Le travail produit intéressant se construit au-dessus : un runtime d’agent qui transforme les conversations SMS en résultats concrets.

Lorsqu’une réponse SMS arrive, réveillez l’agent approprié avec tout le contexte de la conversation : le message sortant qui l’a déclenchée, l’historique du client, l’objectif du fil. Des webhooks, mais pour les agents.

Vendez des objectifs, pas des minutes. Confirmation et reprogrammation de rendez-vous en plusieurs échanges, approfondissement des réponses NPS faibles, qualification de prospects B2B, triage du support. L’agent mène la conversation de bout en bout.

Appliquez l’expertise de TrueDialog en matière de conformité à la couche de réponse. « Ne m’envoyez pas de SMS la nuit » devient une proposition de plages horaires silencieuses, pas un désabonnement complet. Une piste d’audit défendable au regard du TCPA est fournie gratuitement.

Ne remplacez pas vos agents du support. Aidez-les. Réponses rédigées, résumés de fils, suggestions de prochaine meilleure action, le tout présenté dans la console d’agent qu’ils utilisent déjà.

---

Stack

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

Licence

MIT.

Typographie

Lato, JetBrains Mono.