TrueDialog MCP

MCP หรือ Model Context Protocol คือวิธีที่ไคลเอนต์ AI เข้าถึงเครื่องมือและข้อมูลที่จำเป็นเพื่อทำงานจริง tdmcp คือระบบเชื่อมต่อระหว่างไคลเอนต์ที่รองรับ MCP กับ TrueDialog SMS API ซึ่งมีโครงสร้างพื้นฐานของผู้ให้บริการเครือข่ายที่สั่งสมมาสามสิบปี การจัดการการยกเลิกรับข้อความ การสนทนาแบบสองทาง RCS, MMS และการรับส่งข้อความผ่าน short code ทั้งหมดนี้เปิดให้ใช้งานผ่านเครื่องมือจำนวนหนึ่งที่ตั้งชื่อไว้อย่างชัดเจน

การยืนยันตัวตนใช้ OAuth 2.1 ไม่ใช่การวางข้อมูลรับรอง คุณอนุญาตเพียงครั้งเดียวในเบราว์เซอร์ โดยเข้าสู่ระบบที่ auth.tdmcp.com ด้วยบัญชี TrueDialog เดียวกับที่ใช้ในพอร์ทัล ไคลเอนต์ AI ของคุณจะถือเพียง bearer token อายุสั้นเท่านั้น ไม่เคยถือรหัสผ่าน และส่ง token ไปกับทุกการเรียกใช้ ตัวเชื่อมต่อจะตรวจสอบ token และค้นหาสิทธิ์ TrueDialog ของคุณฝั่งเซิร์ฟเวอร์ผ่านช่องทางสื่อสารส่วนตัว ไม่มีข้อมูลที่มีอายุยาวถูกเก็บไว้ใน config ของไคลเอนต์

รันไทม์ตั้งใจให้เรียบง่าย: Azure Container Apps อยู่หลัง front door ที่มีการจัดการ คอนเทนเนอร์ AMD64, FastMCP ให้บริการ Streamable HTTP และไม่มี sticky sessions ใช้ Terraform จัดการทั้งหมด ไม่มีอะไรน่าประหลาดใจ และไม่มีสิ่งใดในเส้นทางการทำงานหลักที่คุณไม่ได้ใส่ไว้เอง

---

Endpoint: https://connect.tdmcp.com ใช้ Streamable HTTP แบบ stateless การขนส่งแบบเดียวกันนี้ยังตอบสนองที่ https://connect.tdmcp.com/mcp ด้วย ซึ่งเป็น alias เพื่อความเข้ากันได้สำหรับไคลเอนต์ที่กำหนดให้ใช้รูปแบบพาธ /mcp ใช้ URL ใดก็ได้ การยืนยันตัวตนใช้ OAuth 2.1 ไคลเอนต์ของคุณจะค้นหาการตั้งค่านี้โดยอัตโนมัติและแนะนำขั้นตอนเข้าสู่ระบบผ่านเบราว์เซอร์ ไม่ต้องวางคีย์หรือเฮดเดอร์ใด ๆ

วิธีการอนุญาต

ไคลเอนต์ทุกตัวด้านล่างทำตามสี่ขั้นตอนเดียวกัน และส่วนใหญ่จะดำเนินการให้คุณโดยอัตโนมัติ:

1. เพิ่ม connect.tdmcp.com ลงในไคลเอนต์ของคุณ
2. ไคลเอนต์ค้นหาเซิร์ฟเวอร์ OAuth ที่ auth.tdmcp.com และลงทะเบียนตัวเองโดยอัตโนมัติ (dynamic client registration, PKCE)
3. หน้าต่างเบราว์เซอร์จะเปิดขึ้น ให้เข้าสู่ระบบด้วยข้อมูลรับรอง TrueDialog ของคุณ
4. ไคลเอนต์ได้รับ token และเชื่อมต่อเรียบร้อยแล้ว ระบบจะต่ออายุ token ให้เอง คุณไม่ต้องเข้าสู่ระบบอีกจนกว่าเซสชันจะหมดอายุ

ใน Claude (แอป Desktop หรือ claude.ai) เปิด Customize → Connectors แล้วคลิก + → Add custom connector ตั้งชื่อและใส่ URL ของ endpoint:

เพิ่ม custom connector

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

คลิก Add แล้วคลิก Connect หน้าต่างเบราว์เซอร์จะเปิดขึ้นเพื่อเข้าสู่ระบบ TrueDialog ให้ยืนยันการอนุญาต แล้วเครื่องมือทั้งเก้ารายการจะปรากฏขึ้น Claude ลงทะเบียนตัวเองกับเซิร์ฟเวอร์ OAuth โดยอัตโนมัติ ไม่ต้องวางข้อมูลใด ๆ สำหรับ Team/Enterprise เจ้าขององค์กรต้องเปิดใช้งานให้กับองค์กรก่อน (Organization settings → Connectors → Add → Custom → Web) จากนั้นสมาชิกแต่ละคนจึงเพิ่มได้จาก Customize → Connectors

---

เครื่องมือ MCP แต่ละรายการเชื่อมโยงกับส่วนเฉพาะของ TrueDialog API โดยตั้งใจให้มีขนาดเล็กและเข้าใจง่าย ส่วนการให้เหตุผลของเอเจนต์อยู่ในพรอมป์ ไม่ใช่ในรายการเครื่องมือ มีทั้งหมดเก้ารายการ — หกรายการสำหรับอ่านข้อมูล และสามรายการสำหรับเขียนข้อมูล

1. whoami
   ส่งคืนผู้ใช้และบัญชีที่อยู่เบื้องหลังเซสชันที่ได้รับอนุญาต ใช้ตรวจสอบการยืนยันตัวตนแบบครั้งเดียวได้ เป็นแบบอ่านอย่างเดียว
2. list_accounts
   แสดงบัญชีทั้งหมดที่ล็อกอินของคุณเข้าถึงได้ ผู้ดูแลหลาย tenant จะเห็นประโยชน์จากรายการนี้ ส่วนผู้ใช้บัญชีเดียวไม่จำเป็นต้องใช้ เป็นแบบอ่านอย่างเดียว
3. get_account_info
   ดึงข้อมูลบัญชีหนึ่งรายการ โดยค่าเริ่มต้นจะใช้บัญชีที่ผ่านการยืนยันตัวตน เป็นแบบอ่านอย่างเดียว
4. list_channels
   แสดงช่องทางต่าง ๆ ของบัญชี เช่น long code, short code, RCS, email และ voice เรียกใช้เพื่อค้นหา channel id ก่อนใช้ send_sms เป็นแบบอ่านอย่างเดียว
5. get_contact
   ค้นหาผู้ติดต่อด้วย id เป็นแบบอ่านอย่างเดียว
6. search_contacts
   ค้นหาข้อความบางส่วนในหมายเลขโทรศัพท์และที่อยู่อีเมล เป็นแบบอ่านอย่างเดียว
7. create_contact
   สร้างผู้ติดต่อจากหมายเลขโทรศัพท์หรืออีเมล (ต้องระบุอย่างน้อยหนึ่งรายการ) หากหมายเลขหรืออีเมลนั้นมีอยู่ในผู้ติดต่อแล้ว TrueDialog จะปฏิเสธการสร้างและแนะนำให้ใช้ update_contact แทน ระบบจะไม่สร้างรายการซ้ำโดยไม่แจ้งให้ทราบ
8. update_contact
   อัปเดตหมายเลขโทรศัพท์ อีเมล หรือชื่อของผู้ติดต่อ โดยจะอ่านระเบียนก่อนแล้วเขียนทับเฉพาะฟิลด์ที่คุณส่งมา เพื่อไม่ให้การอัปเดตแบบเขียนทับทุกอย่างของ TrueDialog ลบข้อมูลส่วนที่เหลือ นี่คือการอ่าน-แก้ไข-เขียน จึงต้องมีสิทธิ์อ่านผู้ติดต่อนอกเหนือจากสิทธิ์จัดการ และไม่ใช่การดำเนินการแบบ atomic หากมีการแก้ไขพร้อมกัน เป็นการเขียนข้อมูล
9. send_sms
   ส่ง SMS ขาออกไปยังหมายเลขหนึ่งรายการหรือหลายรายการ เป็นการส่งจริง โดยค่าเริ่มต้นข้อความจะส่งถึงโทรศัพท์จริง (ส่ง execute=false เพื่อทดลองโดยไม่ส่งจริง) ระบบจะเลือกช่องทางส่งให้อัตโนมัติหากคุณไม่ได้ระบุ เป็นการส่งทางเดียว ไม่อ่านคำตอบกลับ

พูดคุยกับเครื่องมือ

คุณไม่ต้องเรียกเครื่องมือเหล่านี้ด้วยชื่อ แค่ถาม แล้วเอเจนต์จะเลือกเครื่องมือที่เหมาะสมให้ ลองถามสิ่งเหล่านี้เมื่อเชื่อมต่อแล้ว:

• “ฉันเชื่อมต่อในชื่อใครอยู่?” ใช้ยืนยันการยืนยันตัวตน
• “บัญชีของฉันตั้งค่าช่องทางใดไว้บ้าง?” ใช้อ่านช่องทาง
• “ส่งข้อความถึง +1 512 555 0142: ยืนยันโต๊ะสำหรับสี่ท่านเวลา 19:00 น.” ส่งหนึ่งครั้งถึงผู้รับหนึ่งราย
• “ค้นหาผู้ติดต่อของ 512 555 0142 แล้วแจ้งว่าคำสั่งซื้อของพวกเขาจัดส่งแล้ว” ค้นหาและส่งข้อความ

---

ไฟล์แนบใช้งานผ่านเครื่องมืออีเมล inbox_send_message และ inbox_reply_to_message ต่างรับรายการ attachments ส่วน inbox_forward_message จะส่งไฟล์ต้นฉบับไปด้วย (include_attachments เปิดใช้งานโดยค่าเริ่มต้น) แต่ละรายการใน attachments ต้องระบุแหล่งข้อมูลไบต์เพียงแหล่งเดียว และการเลือกแหล่งข้อมูลเป็นตัวกำหนดว่าไฟล์จะส่งถึงหรือไม่

เครื่องมือเหล่านี้อยู่ใน Inbox pack ซึ่งเปิดใช้งานแยกตาม deployment ตัวเชื่อมต่อที่ connect.tdmcp.com แสดงเครื่องมือ TrueDialog ทั้งเก้ารายการข้างต้นในขณะนี้ ส่วนไฟล์แนบจะใช้งานได้พร้อมกับเครื่องมืออีเมลในทุกที่ที่เปิดใช้ Inbox pack

1. attachment_id
   ระบุไฟล์แนบที่แพลตฟอร์มจัดเก็บไว้แล้วในข้อความของ inbox นี้ โดย id มาจาก inbox_get_thread เซิร์ฟเวอร์จะแนบไบต์ที่จัดเก็บไว้ให้เอง จึงไม่มีข้อมูล base64 ผ่านโมเดล วิธีนี้เหมาะกับไฟล์ที่ไม่ใช่ไฟล์ขนาดเล็ก และเป็นแนวทางตามธรรมชาติเมื่อไบต์อยู่ในเธรดที่คุณกำลังตอบกลับอยู่แล้ว filename และ content_type จะสืบทอดมาจากไบต์ที่จัดเก็บไว้ และสามารถแทนที่ได้ วิธีนี้ช่วยข้ามข้อจำกัดด้านการถอดความ แต่ไม่ได้เพิ่มขนาดไฟล์สูงสุด (การส่งต่อไม่จำเป็นต้องใช้วิธีนี้ด้วยซ้ำ: inbox_forward_message จะส่งไฟล์แนบต้นฉบับไปด้วยโดยค่าเริ่มต้น)
2. upload_id
   ระบุไบต์ที่เตรียมไว้ในพื้นที่จัดเก็บแล้ว เป็นวิธีสำหรับไฟล์ใหม่ขนาดใหญ่จริง ๆ POST ไปยัง /v1/inboxes/{inbox_id}/attachments/uploads พร้อมชื่อไฟล์ ชนิด MIME และจำนวนไบต์ที่แน่นอน จากนั้น PUT ไบต์ดิบไปยัง upload_url ที่ลงนามไว้ล่วงหน้าซึ่งระบบส่งกลับมา แล้วระบุ upload_id ในการส่ง ทุกที่ที่เปิดใช้ Inbox pack เครื่องมือ inbox_create_attachment_upload จะทำขั้นตอนแรกและส่งคืน upload_id กับ upload_url ไม่มีเครื่องมือใดทำ PUT ดังนั้นเอเจนต์ที่เข้าถึงได้เฉพาะตัวเชื่อมต่อนี้จึงยังเตรียมไบต์ใหม่ไม่ได้ การอัปโหลดต้องทำจากไคลเอนต์หรือแอปที่สามารถ PUT นอกช่องทางนี้ได้
3. content
   ใส่ base64 โดยตรง พร้อม filename และ content_type ใช้ได้อย่างน่าเชื่อถือเฉพาะกับไฟล์ขนาดเล็กมาก ๆ ประมาณ 2 KB หรือราว 2,700 อักขระ base64 เพราะต้องส่งสตริงทั้งหมดแบบตรงทุกอักขระใน tool call และหากมีอักขระผิดเพียงตัวเดียว การส่งจะล้มเหลวด้วยข้อผิดพลาด base64 padding ที่ไม่ชัดเจน นี่คือขีดจำกัดด้านความน่าเชื่อถือ ไม่ใช่ขีดจำกัดที่ผ่านการตรวจสอบ ระบบจะไม่ปฏิเสธเมื่อไฟล์มีขนาด 2 KB แต่จะรับการส่งไว้แล้วล้มเหลวภายหลังระหว่างถอดรหัส

สิ่งที่เซิร์ฟเวอร์บังคับใช้

มีข้อจำกัดสามข้อ ซึ่งตรวจสอบทั้งหมดที่ฝั่งเซิร์ฟเวอร์:

1. 10 MB ต่อข้อความ รวมขนาดของทุกรายการไม่ว่าจะอยู่ในรูปแบบใด ไบต์ที่อ้างอิงจะนับเต็มจำนวนเหมือนไบต์ที่ใส่โดยตรง การอ้างอิงช่วยให้คุณไม่ต้องถอดความไฟล์ แต่ไม่ได้ทำให้ไฟล์มีขนาดเล็กลง
2. 10 MB ต่อไฟล์ ใช้กับ size_bytes ที่ประกาศไว้ตอนสร้างช่องอัปโหลด จึงไม่มีการออก URL ที่สามารถจัดเก็บออบเจ็กต์ขนาดเกินกำหนดได้
3. 100 รายการ ใน attachments list หนึ่งรายการ

ระบบตรวจสอบยอดรวมจากข้อมูลเมตาที่จัดเก็บไว้ ก่อน ดึงไบต์ และตรวจสอบอีกครั้งเมื่อแก้ไขข้อมูลทั้งหมดแล้ว ดังนั้นการส่งที่เกินขีดจำกัดจะถูกปฏิเสธพร้อม 422 แทนที่จะส่งไปเพียงบางส่วน หากชุดไฟล์เกินขีดจำกัดข้อใดข้อหนึ่ง ให้แบ่งส่งหลายครั้ง

สามารถผสมทั้งสามรูปแบบไว้ในรายการเดียวกันได้ URL อัปโหลดที่ลงนามไว้ล่วงหน้ามีอายุสั้น โดยค่าเริ่มต้นคือ 15 นาที และ PUT ต้องส่ง Content-Type และ Content-Length ให้ตรงกับค่าที่ได้รับทุกประการ เพราะลายเซ็นครอบคลุมทั้งสองค่า การอัปโหลดใช้ได้ครั้งเดียว: การส่งครั้งแรกที่อ้างอิงถึงไฟล์จะใช้สิทธิ์นั้น GET …/attachments/uploads/{upload_id} จะแจ้งว่าช่องยังรอการอัปโหลดอยู่หรือไม่ หมดอายุเมื่อใด และข้อความใดใช้ช่องนั้น แต่จะไม่ตรวจสอบว่า PUT ของคุณอัปโหลดสำเร็จหรือไม่ หากส่งก่อนที่ไบต์จะพร้อม ระบบจะปฏิเสธพร้อม 422 และจะไม่ใช้สิทธิ์อัปโหลด คุณจึงลองใหม่ได้เมื่อ PUT เสร็จแล้ว หากต้องการอ่านข้อมูลกลับ inbox_get_attachment จะส่งคืนไบต์ของไฟล์แนบในรูปแบบ base64

---

เซิร์ฟเวอร์ MCP เป็นจุดเริ่มต้น งานพัฒนาผลิตภัณฑ์ที่น่าสนใจอยู่เหนือชั้นนี้: รันไทม์เอเจนต์ที่เปลี่ยนบทสนทนา SMS ให้เป็นผลลัพธ์ที่ต้องการ

เมื่อมี SMS ตอบกลับ ให้ปลุกเอเจนต์ที่เหมาะสมพร้อมบริบทการสนทนาทั้งหมด: ข้อความขาออกที่ทำให้เกิดการตอบกลับ ประวัติของลูกค้า และเป้าหมายของเธรด เหมือน webhooks แต่สำหรับเอเจนต์

ขายผลลัพธ์ ไม่ใช่นาที ให้เอเจนต์จัดการบทสนทนาหลายรอบตั้งแต่ต้นจนจบ เช่น การยืนยันและเลื่อนนัดหมาย การติดตามคะแนน NPS ต่ำเพื่อเจาะลึก การคัดกรองลูกค้าเป้าหมาย B2B และการคัดแยกคำขอรับการสนับสนุน

นำทรัพย์สินด้านการปฏิบัติตามข้อกำหนดของ TrueDialog มาใช้กับชั้นตอบกลับ “อย่าส่งข้อความหาฉันตอนกลางคืน” จะกลายเป็นข้อเสนอให้ปิดเสียงในช่วงเวลาที่กำหนด ไม่ใช่การยกเลิกรับข้อความทั้งหมด มีบันทึกการตรวจสอบที่รองรับการปฏิบัติตาม TCPA ให้โดยอัตโนมัติ

ไม่ต้องแทนที่เจ้าหน้าที่ฝ่ายสนับสนุน แต่ช่วยให้ทำงานได้ดีขึ้น ทั้งร่างคำตอบ สรุปเธรด และคำแนะนำการดำเนินการถัดไปที่เหมาะสมที่สุด ซึ่งแสดงอยู่ในคอนโซลเอเจนต์ที่พวกเขาใช้อยู่แล้ว

---

เทคโนโลยีที่ใช้

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

สัญญาอนุญาต

MIT.

ฟอนต์

Lato, JetBrains Mono.