TrueDialog MCP

MCP, Model Context Protocol, là cách một ứng dụng AI truy cập các công cụ và dữ liệu cần thiết để thực sự thực hiện công việc. tdmcp là lớp kết nối giữa bất kỳ ứng dụng nào hỗ trợ MCP và TrueDialog SMS API: ba mươi năm hạ tầng nhà mạng, xử lý yêu cầu từ chối nhận tin, hội thoại hai chiều, RCS, MMS và lưu lượng mã ngắn, được cung cấp qua một bộ công cụ nhỏ với tên gọi rõ ràng.

Xác thực bằng OAuth 2.1, không phải thông tin đăng nhập được dán vào. Bạn chỉ cần cấp quyền một lần trong trình duyệt, thông qua auth.tdmcp.com — đăng nhập bằng cùng tài khoản TrueDialog mà bạn dùng cho cổng thông tin. Ứng dụng AI của bạn chỉ giữ một bearer token có thời hạn ngắn, không bao giờ giữ mật khẩu, và gửi token đó trong mỗi lần gọi. Trình kết nối xác thực token và phân giải quyền truy cập TrueDialog của bạn ở phía máy chủ thông qua một kênh phụ riêng tư. Không có thông tin nào tồn tại lâu dài được lưu trong cấu hình ứng dụng của bạn.

Môi trường chạy được cố ý giữ ở mức bình thường: Azure Container Apps phía sau một front-door được quản lý, container AMD64, FastMCP phục vụ Streamable HTTP, không có phiên cố định. Terraform quản lý toàn bộ. Không có gì bất ngờ, không có gì trong đường xử lý chính mà bạn không chủ động đưa vào.

---

Endpoint: https://connect.tdmcp.com. Streamable HTTP, không trạng thái. Cùng một giao thức truyền tải cũng phản hồi tại https://connect.tdmcp.com/mcp — một bí danh tương thích dành cho các ứng dụng mặc định dùng quy ước đường dẫn /mcp; cả hai URL đều hoạt động. Xác thực bằng OAuth 2.1 — ứng dụng của bạn tự động tìm thông tin cần thiết và hướng dẫn bạn đăng nhập trong trình duyệt. Không có khóa hay header nào cần dán vào.

Cách hoạt động của việc cấp quyền

Mọi ứng dụng dưới đây đều thực hiện cùng bốn bước, và phần lớn diễn ra tự động:

1. Bạn thêm connect.tdmcp.com vào ứng dụng của mình.
2. Ứng dụng tìm máy chủ OAuth tại auth.tdmcp.com và tự động đăng ký (đăng ký ứng dụng động, PKCE).
3. Một cửa sổ trình duyệt mở ra. Bạn đăng nhập bằng thông tin đăng nhập TrueDialog.
4. Ứng dụng nhận token và kết nối thành công. Ứng dụng tự làm mới token — bạn sẽ không phải đăng nhập lại cho đến khi phiên hết hạn.

Trong Claude (ứng dụng Desktop hoặc claude.ai), mở Customize → Connectors rồi nhấp + → Add custom connector. Đặt tên và nhập URL endpoint:

thêm trình kết nối tùy chỉnh

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

Nhấp Add, rồi Connect. Một cửa sổ trình duyệt mở ra để đăng nhập TrueDialog; hãy phê duyệt, rồi chín công cụ sẽ xuất hiện — Claude tự động đăng ký với máy chủ OAuth, không cần dán gì cả. Với gói Team/Enterprise, Owner phải bật tính năng này cho tổ chức trước (Organization settings → Connectors → Add → Custom → Web); sau đó, mỗi thành viên thêm trình kết nối từ Customize → Connectors.

---

Mỗi công cụ MCP ánh xạ tới một bề mặt API TrueDialog cụ thể. Các công cụ được cố ý thiết kế nhỏ gọn và dễ hiểu; phần suy luận của agent nằm trong prompt, không nằm trong danh sách công cụ. Tổng cộng có chín công cụ — sáu công cụ chỉ đọc, ba công cụ ghi dữ liệu.

1. whoami
   Trả về người dùng và tài khoản gắn với phiên đã được cấp quyền. Hữu ích để kiểm tra xác thực nhanh một lần. Chỉ đọc.
2. list_accounts
   Liệt kê mọi tài khoản mà thông tin đăng nhập của bạn có thể truy cập. Hữu ích với người vận hành nhiều tenant; người dùng chỉ có một tài khoản thì không cần. Chỉ đọc.
3. get_account_info
   Lấy một bản ghi tài khoản. Mặc định là tài khoản đã xác thực. Chỉ đọc.
4. list_channels
   Liệt kê các kênh — long code, short code, RCS, email, voice — trên một tài khoản. Gọi công cụ này để tìm channel id trước khi dùng send_sms. Chỉ đọc.
5. get_contact
   Tìm một liên hệ theo id. Chỉ đọc.
6. search_contacts
   Tìm chuỗi con trong số điện thoại và địa chỉ email. Chỉ đọc.
7. create_contact
   Tạo liên hệ từ số điện thoại hoặc email (bắt buộc có ít nhất một thông tin). Nếu số điện thoại hoặc email đó đã có trong một liên hệ, TrueDialog sẽ từ chối tạo và hướng bạn đến update_contact — hệ thống sẽ không âm thầm tạo bản trùng lặp.
8. update_contact
   Cập nhật số điện thoại, email hoặc tên của một liên hệ. Công cụ đọc bản ghi trước rồi chỉ ghi lại các trường bạn truyền vào, nhờ đó thao tác cập nhật vốn ghi đè mọi thứ của TrueDialog không xóa các trường còn lại — đây là thao tác đọc-sửa-ghi, nên ngoài quyền manage còn cần quyền contact-read, và không có tính nguyên tử nếu có chỉnh sửa đồng thời. Đây là thao tác ghi.
9. send_sms
   Gửi SMS đi đến một hoặc nhiều số điện thoại. Đây là gửi thật: mặc định tin nhắn sẽ đến điện thoại thật (truyền execute=false để chạy thử). Tự động phân giải kênh gửi nếu bạn không chỉ định. Một chiều — công cụ không đọc tin nhắn trả lời.

Hãy trò chuyện với nó.

Bạn không gọi các công cụ này bằng tên — chỉ cần yêu cầu, agent sẽ chọn công cụ phù hợp. Sau đây là một vài câu bạn có thể thử sau khi kết nối:

• “Tôi đang kết nối với tư cách nào?” để xác nhận xác thực
• “Tài khoản của tôi đã thiết lập những kênh nào?” để xem các kênh
• “Nhắn tin đến +1 512 555 0142: bàn cho bốn người của bạn đã được xác nhận lúc 7pm.” gửi một tin, một người nhận
• “Tìm liên hệ của 512 555 0142 và báo cho họ biết đơn hàng đã được gửi.” tìm liên hệ rồi gửi tin

---

Tệp đính kèm được xử lý qua các công cụ email. inbox_send_message và inbox_reply_to_message đều nhận danh sách attachments; inbox_forward_message thay vào đó tự mang theo các tệp gốc (include_attachments, mặc định bật). Mỗi mục trong danh sách attachments chỉ định chính xác một nguồn dữ liệu byte, và việc bạn chọn nguồn nào sẽ quyết định tệp có được gửi đến nơi hay không.

Các công cụ đó thuộc gói Inbox, được bật riêng cho từng lần triển khai. Trình kết nối tại connect.tdmcp.com hiện quảng bá chín công cụ TrueDialog ở trên; tệp đính kèm được hỗ trợ cùng các công cụ email, ở bất cứ nơi nào gói Inbox được bật.

1. attachment_id
   Chỉ định một tệp đính kèm mà nền tảng đã lưu, trong một tin nhắn thuộc hộp thư này — id được lấy từ inbox_get_thread. Máy chủ tự đính kèm lại dữ liệu byte đã lưu, nên không có dữ liệu base64 nào đi qua mô hình. Đây là lựa chọn phù hợp cho mọi tệp không nhỏ và là cách tự nhiên nhất khi dữ liệu byte đã có trong chuỗi hội thoại mà bạn đang trả lời. filename và content_type được kế thừa từ dữ liệu byte đã lưu và có thể được ghi đè. Cách này loại bỏ giới hạn phiên âm, chứ không loại bỏ giới hạn kích thước. (Khi chuyển tiếp, bạn thậm chí không cần dùng cách này: inbox_forward_message mặc định mang theo các tệp đính kèm gốc.)
2. upload_id
   Chỉ định dữ liệu byte đã được đưa vào vùng lưu trữ tạm — cách dùng cho một tệp lớn hoàn toàn mới. POST đến /v1/inboxes/{inbox_id}/attachments/uploads cùng tên tệp, loại MIME và độ dài byte chính xác; PUT dữ liệu byte thô đến upload_url được ký sẵn mà hệ thống trả về; sau đó đưa upload_id vào yêu cầu gửi. Ở mọi nơi gói Inbox được bật, inbox_create_attachment_upload thực hiện bước đầu tiên và trả về upload_id cùng upload_url. Không công cụ nào thực hiện PUT, vì vậy agent chỉ có thể truy cập trình kết nối này vẫn không thể đưa dữ liệu byte mới vào vùng lưu trữ; việc tải lên phải được thực hiện bởi một ứng dụng hoặc app có thể PUT ngoài băng.
3. content
   Dữ liệu base64 nội tuyến, được cung cấp cùng filename và content_type. Chỉ đáng tin cậy với các tệp rất nhỏ — khoảng 2 KB, tương đương 2.700 ký tự base64 — vì toàn bộ chuỗi phải được xuất chính xác từng ký tự trong lần gọi công cụ, và chỉ cần sai một ký tự là thao tác gửi thất bại với lỗi padding base64 khó hiểu. Đây là giới hạn về độ tin cậy, không phải giới hạn đã được xác thực: không có gì từ chối bạn ở mức 2 KB. Yêu cầu gửi được chấp nhận rồi mới thất bại ở bước giải mã.

Những giới hạn máy chủ áp dụng

Ba giới hạn, tất cả đều được kiểm tra ở phía máy chủ:

1. 10 MB cho mỗi tin nhắn, tính tổng mọi mục bất kể hình thức — dữ liệu byte được tham chiếu vẫn được tính đầy đủ, giống hệt dữ liệu nội tuyến. Tham chiếu đến tệp giúp bạn không phải phiên âm tệp; nó không làm tệp nhỏ hơn.
2. 10 MB cho mỗi tệp, áp dụng cho size_bytes đã khai báo khi tạo chỗ tải lên — vì vậy không bao giờ có URL cho phép lưu một đối tượng vượt quá kích thước.
3. 100 mục trong một danh sách attachments.

Tổng dung lượng được kiểm tra từ metadata đã lưu trước khi lấy dữ liệu byte, rồi kiểm tra lại sau khi phân giải tất cả, vì vậy yêu cầu gửi vượt giới hạn sẽ bị từ chối bằng 422 thay vì gửi một phần. Nếu một tập tệp vượt quá một trong hai giới hạn, hãy chia thành nhiều lần gửi.

Có thể kết hợp tự do cả ba hình thức trong cùng một danh sách. URL tải lên được ký sẵn có thời hạn ngắn — mặc định 15 phút — và PUT phải gửi chính xác Content-Type và Content-Length được cung cấp, vì chữ ký bao gồm cả hai giá trị này. Mỗi lần tải lên chỉ dùng được một lần: lần gửi đầu tiên tham chiếu đến nó sẽ tiêu thụ lượt tải lên đó. GET …/attachments/uploads/{upload_id} cho biết chỗ tải lên còn đang chờ xử lý hay không, khi nào hết hạn và tin nhắn nào đã sử dụng nó; thao tác này không kiểm tra xem PUT đã được tải lên hay chưa. Nếu gửi trước khi dữ liệu byte có mặt, yêu cầu sẽ bị từ chối bằng 422 và không tiêu thụ lượt tải lên, nên bạn có thể thử lại sau khi PUT hoàn tất. Theo chiều ngược lại, inbox_get_attachment trả về dữ liệu byte của tệp đính kèm được mã hóa base64.

---

Máy chủ MCP là điểm khởi đầu. Công việc sản phẩm thú vị nằm ở phần xây dựng trên đó: một môi trường chạy agent biến các cuộc hội thoại SMS thành kết quả cụ thể.

Khi có tin nhắn SMS trả lời, hãy đánh thức đúng agent với đầy đủ ngữ cảnh hội thoại: tin nhắn gửi đi đã kích hoạt phản hồi, lịch sử của khách hàng và mục tiêu của chuỗi hội thoại. Webhook, nhưng dành cho agent.

Bán kết quả, không bán số phút. Xác nhận và đổi lịch hẹn qua nhiều lượt hội thoại, tìm hiểu sâu hơn về NPS khi điểm số thấp, đánh giá khách hàng tiềm năng B2B, phân loại yêu cầu hỗ trợ. Agent xử lý cuộc hội thoại từ đầu đến cuối.

Áp dụng chuyên môn tuân thủ của TrueDialog vào lớp phản hồi. “Đừng nhắn tin cho tôi vào ban đêm” trở thành đề xuất về giờ yên tĩnh, thay vì hủy đăng ký hoàn toàn. Nhật ký kiểm toán có thể bảo vệ theo TCPA được cung cấp miễn phí.

Đừng thay thế nhân viên hỗ trợ. Hãy hỗ trợ họ. Soạn sẵn câu trả lời, tóm tắt chuỗi hội thoại, đề xuất hành động tiếp theo phù hợp nhất — tất cả được hiển thị ngay trong bảng điều khiển agent mà họ đang dùng.

---

Stack

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

Giấy phép

MIT.

Thiết kế bằng

Lato, JetBrains Mono.