TrueDialog MCP

आधिकारिक

TrueDialog, आपके AI Agent से जुड़ा हुआ। पुरस्कार-विजेता TrueDialog प्लेटफ़ॉर्म के ज़रिए ओम्नी-चैनल संदेश भेजें और संपर्कों को प्रबंधित करें। अपने मौजूदा TrueDialog खाते का उपयोग करके व्यावसायिक SMS और RCS भेजने तथा संपर्कों को प्रबंधित करने के लिए अपने AI Agent को TrueDialog से कनेक्ट करें। संपर्क खोजें और प्राप्त करें, संपर्क रिकॉर्ड बनाएँ या अपडेट करें, खाते का विवरण और कॉन्फ़िगर किए गए 10DLC/लॉन्ग-कोड तथा शॉर्ट-कोड चैनल देखें, और एक या कई प्राप्तकर्ताओं को आउटबाउंड टेक्स्ट संदेश भेजें। SMS और RCS मार्केटिंग आउटरीच, अलर्ट और सूचनाओं, अपॉइंटमेंट और इवेंट रिमाइंडर, बिक्री संबंधी फ़ॉलो-अप, ग्राहक-सेवा अपडेट और कर्मचारी संचार के लिए TrueDialog का उपयोग करें। विश्वसनीय और अनुपालन-अनुकूल SMS वर्कफ़्लो को समर्थन देने के लिए संदेश TrueDialog के सीधे कैरियर कनेक्शन और अंतर्निहित ऑप्ट-आउट प्रबंधन का उपयोग करते हैं।

tdmcp.com पर देखें

TrueDialog MCP के साथ आप क्या कर सकते हैं?

  • अपना सत्र जाँचें — त्वरित प्रमाणीकरण जाँच के लिए पूछें कि आपका अधिकृत कनेक्शन किस TrueDialog उपयोगकर्ता और खाते के रूप में काम कर रहा है।
  • खाते और चैनल ब्राउज़ करें — आपके लॉगिन को दिखाई देने वाले सभी खाते सूचीबद्ध करें, किसी एक खाते का विवरण प्राप्त करें, या उसके SMS, RCS, ईमेल और वॉइस चैनल सूचीबद्ध करें।
  • संपर्क खोजें — आईडी से संपर्क का विवरण प्राप्त करें या फ़ोन नंबरों और ईमेल पतों में किसी अंश के आधार पर खोजें।
  • संपर्क बनाएँ या अपडेट करें — फ़ोन नंबर या ईमेल से संपर्क जोड़ें, या बाकी जानकारी को बदले बिना केवल आपके दिए गए फ़ील्ड अपडेट करें।
  • SMS भेजें — एक या अधिक नंबरों पर टेक्स्ट भेजें; ड्राई रन का विकल्प उपलब्ध है। यदि आप कोई चैनल निर्दिष्ट नहीं करते, तो कनेक्टर भेजने के लिए चैनल चुन लेगा।

दस्तावेज़

MCP, Model Context Protocol, वह तरीका है जिससे कोई AI क्लाइंट उन टूल और डेटा तक पहुँचता है जिनकी उसे वास्तव में कुछ करने के लिए ज़रूरत होती है। tdmcp, MCP बोलने वाले किसी भी क्लाइंट और TrueDialog SMS API के बीच का आधारभूत ढाँचा है: कैरियर इन्फ्रास्ट्रक्चर के तीस साल, ऑप्ट-आउट प्रबंधन, दो-तरफ़ा बातचीत, RCS, MMS और शॉर्ट-कोड ट्रैफ़िक—ये सब सुव्यवस्थित नामों वाले कुछ टूल के रूप में उपलब्ध हैं।

प्रमाणीकरण OAuth 2.1 से होता है, चिपकाए गए क्रेडेंशियल से नहीं। आप अपने ब्राउज़र में एक बार auth.tdmcp.com पर अनुमति देते हैं—उसी TrueDialog लॉगिन से साइन इन करके जिसका उपयोग आप पोर्टल के लिए करते हैं। आपका AI क्लाइंट केवल थोड़े समय तक मान्य bearer token रखता है, आपका पासवर्ड कभी नहीं, और हर कॉल के साथ उसे भेजता है। कनेक्टर टोकन की पुष्टि करता है और निजी बैक-चैनल के ज़रिए सर्वर-साइड पर आपके TrueDialog एक्सेस का पता लगाता है। आपके क्लाइंट कॉन्फ़िगरेशन में कोई भी लंबे समय तक मान्य जानकारी नहीं रहती।

रनटाइम जानबूझकर साधारण रखा गया है: प्रबंधित फ्रंट-डोर के पीछे Azure Container Apps, AMD64 कंटेनर, Streamable HTTP उपलब्ध कराने वाला FastMCP, कोई स्टिकी सेशन नहीं। पूरे सेटअप के लिए Terraform। कुछ भी अप्रत्याशित नहीं, हॉट पाथ में ऐसा कुछ नहीं जिसे आपने वहाँ न रखा हो।

एंडपॉइंट: https://connect.tdmcp.com। Streamable HTTP, स्टेटलेस। यही ट्रांसपोर्ट https://connect.tdmcp.com/mcp पर भी जवाब देता है — उन क्लाइंट के लिए एक संगतता उपनाम जो /mcp पाथ कन्वेंशन मानकर चलते हैं; दोनों में से कोई भी URL काम करता है। प्रमाणीकरण OAuth 2.1 से होता है — आपका क्लाइंट इसे अपने-आप खोज लेता है और ब्राउज़र में साइन-इन की प्रक्रिया में आपका मार्गदर्शन करता है। चिपकाने के लिए कोई कुंजी या हेडर नहीं हैं।

प्राधिकरण कैसे काम करता है

नीचे दिए गए हर क्लाइंट में यही चार चरण होते हैं, और इनमें से ज़्यादातर अपने-आप हो जाते हैं:

  1. आप अपने क्लाइंट में connect.tdmcp.com जोड़ते हैं।
  2. क्लाइंट auth.tdmcp.com पर OAuth सर्वर ढूँढ़ता है और अपने-आप पंजीकरण करता है (डायनेमिक क्लाइंट रजिस्ट्रेशन, PKCE)।
  3. ब्राउज़र विंडो खुलती है। आप अपने TrueDialog क्रेडेंशियल से साइन इन करते हैं।
  4. आपके क्लाइंट को टोकन मिलता है और आपका कनेक्शन स्थापित हो जाता है। यह टोकन अपने-आप रिफ़्रेश होता है — सेशन की अवधि समाप्त होने तक आपको दोबारा साइन इन नहीं करना होगा।

Claude (Desktop app या claude.ai) में Customize → Connectors खोलें और + → Add custom connector पर क्लिक करें। इसे एक नाम दें और एंडपॉइंट URL डालें:

कस्टम कनेक्टर जोड़ें

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

Add पर क्लिक करें, फिर Connect पर। TrueDialog में साइन-इन करने के लिए ब्राउज़र विंडो खुलेगी; अनुमति दें और नौ टूल दिखाई देंगे — Claude OAuth सर्वर के साथ अपने-आप पंजीकरण करता है, कुछ भी चिपकाने की ज़रूरत नहीं। Team/Enterprise में, Owner को पहले संगठन के लिए इसे सक्षम करना होगा (Organization settings → Connectors → Add → Custom → Web); इसके बाद हर सदस्य इसे Customize → Connectors से जोड़ सकता है।

हर MCP टूल, TrueDialog API के एक विशिष्ट हिस्से से जुड़ा है। इन्हें जानबूझकर छोटा और स्पष्ट रखा गया है; एजेंट का तर्क प्रॉम्प्ट में होता है, टूल सूची में नहीं। कुल नौ टूल — छह केवल पढ़ने के लिए, तीन लिखने वाले।

  1. whoami
    आपके अधिकृत सेशन के पीछे मौजूद उपयोगकर्ता और खाते की जानकारी देता है। एक बार में प्रमाणीकरण जाँचने के लिए उपयोगी। केवल पढ़ने के लिए।
  2. list_accounts
    आपके लॉगिन से दिखाई देने वाले सभी खाते सूचीबद्ध करता है। कई टेनेंट पर काम करने वाले ऑपरेटरों के लिए उपयोगी; एक खाते वाले उपयोगकर्ताओं के लिए नहीं। केवल पढ़ने के लिए।
  3. get_account_info
    एक खाते का रिकॉर्ड प्राप्त करता है। डिफ़ॉल्ट रूप से प्रमाणित खाते का रिकॉर्ड देता है। केवल पढ़ने के लिए।
  4. list_channels
    किसी खाते के चैनल — long code, short code, RCS, email, voice — सूचीबद्ध करता है। send_sms से पहले चैनल ID ढूँढ़ने के लिए इसे कॉल करें। केवल पढ़ने के लिए।
  5. get_contact
    ID से किसी संपर्क को खोजता है। केवल पढ़ने के लिए।
  6. search_contacts
    फ़ोन नंबर और ईमेल पतों में सबस्ट्रिंग मिलान करता है। केवल पढ़ने के लिए।
  7. create_contact
    फ़ोन नंबर या ईमेल से संपर्क बनाता है (कम-से-कम एक देना ज़रूरी है)। अगर वह नंबर या ईमेल पहले से किसी संपर्क में है, तो TrueDialog संपर्क बनाने से मना करता है और update_contact का उपयोग करने को कहता है — यह चुपचाप डुप्लिकेट नहीं बनाता।
  8. update_contact
    किसी संपर्क का फ़ोन, ईमेल या नाम अपडेट करता है। यह पहले रिकॉर्ड पढ़ता है और केवल आपके दिए गए फ़ील्ड दोबारा लिखता है, ताकि TrueDialog का सब कुछ ओवरराइट करने वाला अपडेट बाकी जानकारी न मिटा दे — यह read-modify-write प्रक्रिया है, इसलिए इसके लिए manage के साथ contact-read अनुमति भी चाहिए, और एक साथ होने वाले संपादन के विरुद्ध यह एटॉमिक नहीं है। लिखने वाला टूल।
  9. send_sms
    एक या अधिक नंबरों पर आउटबाउंड SMS भेजता है। यह वास्तविक संदेश भेजता है: डिफ़ॉल्ट रूप से संदेश असली फ़ोन तक पहुँचता है (ड्राई रन के लिए execute=false दें)। अगर आप चैनल का नाम नहीं देते, तो यह अपने-आप भेजने वाला चैनल चुनता है। एकतरफ़ा — यह जवाब नहीं पढ़ता।

इससे बात करें।

आप इन टूल को नाम लेकर कॉल नहीं करते — आप बस अनुरोध करते हैं और एजेंट सही टूल चुनता है। कनेक्ट होने के बाद आज़माने के लिए कुछ उदाहरण:

  • “मैं किस खाते से जुड़ा हूँ?” प्रमाणीकरण की पुष्टि करता है
  • “मेरे खाते पर कौन-से चैनल सेट अप हैं?” चैनल पढ़ता है
  • “+1 512 555 0142 पर टेक्स्ट भेजें: चार लोगों के लिए आपकी टेबल शाम 7 बजे के लिए पक्की है।” एक संदेश, एक प्राप्तकर्ता
  • “512 555 0142 का संपर्क ढूँढ़ें और उन्हें बताएं कि उनका ऑर्डर भेज दिया गया है।” खोजता है और संदेश भेजता है

फ़ाइलें ईमेल टूल के ज़रिए भेजी जाती हैं। inbox_send_message और inbox_reply_to_message, दोनों attachments सूची लेते हैं; inbox_forward_message इसके बजाय मूल फ़ाइलें अपने साथ भेजता है (include_attachments, डिफ़ॉल्ट रूप से चालू)। attachments सूची की हर प्रविष्टि में बाइट्स का ठीक एक स्रोत दिया जाता है, और चुना गया स्रोत ही तय करता है कि फ़ाइल पहुँचेगी या नहीं।

ये टूल Inbox pack का हिस्सा हैं, जिसे हर डिप्लॉयमेंट के लिए अलग से सक्षम किया जाता है। connect.tdmcp.com पर मौजूद कनेक्टर अभी ऊपर दिए गए नौ TrueDialog टूल उपलब्ध कराता है; ईमेल टूल के साथ अटैचमेंट वहाँ उपलब्ध होते हैं जहाँ Inbox pack चालू हो।

  1. attachment_id
    इस इनबॉक्स के किसी संदेश पर प्लेटफ़ॉर्म में पहले से मौजूद अटैचमेंट का नाम बताता है — ये ID inbox_get_thread से मिलती हैं। सर्वर खुद संग्रहीत बाइट्स दोबारा अटैच करता है, इसलिए कोई base64 मॉडल से होकर नहीं गुजरता। जो फ़ाइल बहुत छोटी नहीं है, उसके लिए यही सही विकल्प है; और जब बाइट्स पहले से उस थ्रेड में हों जिसका आप जवाब दे रहे हैं, तो यही स्वाभाविक तरीका है। filename और content_type संग्रहीत बाइट्स से लिए जाते हैं और इन्हें बदला जा सकता है। इससे ट्रांसक्रिप्शन की सीमा हटती है, आकार की सीमा नहीं। (फ़ॉरवर्ड करने के लिए इसकी ज़रूरत भी नहीं: inbox_forward_message डिफ़ॉल्ट रूप से मूल अटैचमेंट साथ भेजता है।)
  2. upload_id
    स्टोरेज में पहले से रखी गई बाइट्स का नाम बताता है — सचमुच नई और बड़ी फ़ाइल के लिए यही तरीका है। फ़ाइल का नाम, MIME प्रकार और बाइट्स की सटीक लंबाई देकर /v1/inboxes/{inbox_id}/attachments/uploads पर POST; फिर उससे मिले presigned upload_url पर कच्ची बाइट्स PUT; इसके बाद अपने संदेश में upload_id दें। जहाँ भी Inbox pack चालू है, inbox_create_attachment_upload पहला चरण पूरा करता है और upload_id तथा upload_url लौटाता है। कोई टूल PUT नहीं करता, इसलिए अगर किसी एजेंट की पहुँच केवल इस कनेक्टर तक है, तो वह नई बाइट्स स्टेज नहीं कर सकता; अपलोड किसी ऐसे क्लाइंट या ऐप से करना होगा जो अलग माध्यम से PUT कर सके।
  3. content
    filename और content_type के साथ इनलाइन base64 देता है। यह केवल बहुत छोटी फ़ाइलों के लिए भरोसेमंद है — लगभग 2 KB, यानी करीब 2,700 base64 अक्षर — क्योंकि पूरी स्ट्रिंग को टूल कॉल में अक्षर-दर-अक्षर भेजना पड़ता है, और एक भी गलत अक्षर होने पर अस्पष्ट base64 padding त्रुटि के साथ संदेश भेजना विफल हो जाता है। यह भरोसेमंदी की सीमा है, सत्यापित सीमा नहीं: 2 KB पर आपको कोई नहीं रोकेगा। संदेश स्वीकार हो जाता है और बाद में, डिकोडिंग के दौरान विफल होता है।

सर्वर किन सीमाओं को लागू करता है

तीन सीमाएँ, सभी की जाँच सर्वर-साइड पर होती है:

  1. हर संदेश के लिए 10 MB, सभी प्रविष्टियों का कुल आकार, चाहे उनका रूप कुछ भी हो — संदर्भित बाइट्स भी पूरी गिनी जाती हैं, ठीक इनलाइन बाइट्स की तरह। संदर्भ देने से फ़ाइल को अक्षर-दर-अक्षर लिखने की ज़रूरत नहीं रहती; फ़ाइल छोटी नहीं होती।
  2. हर फ़ाइल के लिए 10 MB, upload slot बनाते समय घोषित size_bytes पर लागू — इसलिए कभी ऐसा URL जारी नहीं होता जो सीमा से बड़ी वस्तु स्टोर कर सके।
  3. एक attachments सूची में 100 प्रविष्टियाँ।

कुल आकार की जाँच संग्रहीत मेटाडेटा से बाइट्स प्राप्त करने से पहले और फिर सब कुछ हल हो जाने के बाद की जाती है, इसलिए सीमा से बड़ा संदेश आंशिक रूप से भेजे जाने के बजाय 422 के साथ अस्वीकार कर दिया जाता है। अगर कोई सेट इनमें से किसी भी सीमा से बड़ा हो, तो उसे कई संदेशों में बाँटें।

एक ही सूची में तीनों रूपों को मिलाकर इस्तेमाल किया जा सकता है। Presigned upload URL थोड़े समय के लिए मान्य होते हैं — डिफ़ॉल्ट रूप से 15 मिनट — और PUT को आपको वही Content-Type और Content-Length भेजना होगा जो आपको दिए गए थे, क्योंकि हस्ताक्षर में दोनों शामिल हैं। अपलोड का उपयोग केवल एक बार किया जा सकता है: उसका संदर्भ देने वाला पहला संदेश उसे इस्तेमाल कर लेता है। GET …/attachments/uploads/{upload_id} आपको बताता है कि स्लॉट अभी लंबित है या नहीं, उसकी अवधि कब समाप्त होगी और किस संदेश ने उसका उपयोग किया; यह जाँच नहीं करता कि आपका PUT पहुँच गया है या नहीं। बाइट्स पहुँचने से पहले भेजा गया संदेश 422 के साथ अस्वीकार कर दिया जाता है और अपलोड का उपयोग नहीं करता, इसलिए PUT पूरा होने के बाद आप फिर कोशिश कर सकते हैं। दूसरी दिशा में, inbox_get_attachment किसी अटैचमेंट की बाइट्स base64-एन्कोडेड रूप में लौटाता है।

MCP सर्वर प्रवेश-द्वार है। दिलचस्प उत्पाद काम इसके ऊपर होता है: ऐसा एजेंट रनटाइम जो SMS बातचीत को नतीजों में बदलता है।

जब SMS का जवाब आता है, तो सही एजेंट को पूरी बातचीत के संदर्भ के साथ सक्रिय करें: वह आउटबाउंड संदेश जिसने जवाब शुरू किया, ग्राहक का इतिहास और थ्रेड का लक्ष्य। वेबहुक, लेकिन एजेंटों के लिए।

मिनट नहीं, लक्ष्य बेचें। कई चरणों में अपॉइंटमेंट की पुष्टि और समय बदलना, कम स्कोर पर NPS के बारे में आगे पूछना, B2B लीड की योग्यता जाँचना, सहायता अनुरोधों की छँटाई। एजेंट बातचीत को शुरू से अंत तक संभालता है।

जवाब देने की परत पर TrueDialog की अनुपालन विशेषज्ञता लागू करें। “रात में मुझे टेक्स्ट न करें” का जवाब पूरी तरह सदस्यता समाप्त करने के बजाय शांत समय का विकल्प देकर दें। TCPA के अनुरूप ऑडिट ट्रेल अपने-आप मिलता है।

अपने सहायता प्रतिनिधियों की जगह न लें। उनकी मदद करें। सुझाए गए जवाब, थ्रेड के सारांश और अगली सबसे अच्छी कार्रवाई के सुझाव — ये सब उसी एजेंट कंसोल में दिखाएँ जिसका वे पहले से उपयोग करते हैं।

स्टैक

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

लाइसेंस

MIT।

फ़ॉन्ट

Lato, JetBrains Mono।