ClickSend SMS API + MCP vs Wati

ClickSend SMS API + MCP 37

No public OpenAPI spec found. The MCP package bundles an OpenAPI 3.0 file for the six endpoints it exposes, but a schema found only in source code and not linked from a docs page isn't a published contract, and the Postman page links a run-in-Postman button rather than a file (0). llms.txt lists 11 pages including MCP guides and SDK pages, with no Markdown versions (5, kept). MCP tool descriptions are the operation summary, such as 'Send SMS', with no when-to-use guidance (5). Typed inputs generated from the spec (10). Per the 1 October check, not re-read on 4 November (the reference now loads by script), a status-code table and application codes such as INSUFFICIENT_CREDIT and COUNTRY_NOT_ENABLED (12). /v3 path, SDK migration guides and no public API changelog (5). 0+5+5+10+12+5 = 37.

Wati 79

No standalone spec file was found, but every reference page embeds the OpenAPI 3.0.4 contract for its operation, with the documentation version 2.6 (20 of 25). llms.txt and Markdown pages (10). Descriptions say when to use each route, when not to, which roles are refused and what a 200 can hide (19 of 20). Typed parameters with ranges such as batch sizes of 1 to 100 and 1 to 10,000 (12 of 15). Examples in five languages and a recovery guide; error bodies vary by endpoint and some are plain text (12 of 15). Versioned documentation and a public roadmap, but no changelog (6 of 15). 20 + 10 + 19 + 12 + 12 + 6 = 79.

ClickSend SMS API + MCP 70

6 MCP tools, with inputs generated from the spec (20 of 25). Pages with page and limit (15 to 100) and a next_page_url, and SMS history filters by date, which the MCP parses from natural language (20). HTTP and application error codes, though the MCP returns them as plain text (15 of 20). No idempotency key on sends and no tool annotations (0 of 20). SDKs in ten languages, and a send needs only a recipient and a body (15).

Wati 48

The MCP catalogue lists 73 WATI tools plus Astra groups, some loaded on demand through list_skills and activate_skill (10 of 25). Page and page size with filters on lists, and bounded search (17 of 20). Error handling is documented per status, but bodies can be JSON, plain text or empty, so an agent can't rely on one shape (10 of 20). No idempotency keys; tag add and remove are idempotent, and the docs say to reconcile rather than retry sends (5 of 20). No official SDK; runnable examples in five languages, and region-specific hosts add setup (6 of 15). 10 + 17 + 10 + 5 + 6 = 48.

ClickSend SMS API + MCP 64

Closed service with terms from ClickSend Pty Ltd. The MCP server is MIT (15). The privacy policy still says it was last updated in September 2023 and names no retention periods. The sub-processor page now loads and says message data held by AWS is deleted after 120 days. The DPA terms are a linked PDF we can't read (15 of 30). No deprecation policy found; the v1 SDKs are marked deprecated with no date, and the legacy HTTP v2 and SMPP APIs are still documented (0). The sub-processor list names each provider with the data, purpose and hosting location (AWS in Australia, Datadog in North America, Sinch entities by country) and promises an update at least 10 days before a new one, as Sinch's list is read (20). 15+15+0+20 = 50.

Wati 52

Closed service with clear terms from Clare.AI Limited (8 December 2025); the MCP repository is MIT (15 of 30). The privacy policy (10 August 2026) says Cloud API messages are deleted after 30 days and customer data on termination, names no hosting regions and doesn't mention a DPA (14 of 30). Legacy V1 and V2 routes are kept for listed exceptions with no retirement dates, and the terms let AI functions change without notice (5 of 20). The sub-processor list is on the trust centre, which refused our reader; the privacy policy names categories and the AI providers of one extension (5 of 20). 15 + 14 + 5 + 5 = 39.

ClickSend SMS API + MCP 65

Statuspage at status.clicksend.com with component history, read through its history.atom feed on 4 November (20). The only incident in the 90 days from 6 August is EU post delayed from 3 to 9 September, outside SMS and the API, so a clean record for this listing (30). No rate limit numbers published (0). Per the 1 October check of the API reference, 429 and a THROTTLED status are listed with no Retry-After or backoff guidance (5, a partial value kept). The reference now renders only by script and wasn't re-read on 4 November. No SLA found (0). REST API v3 is generally available (10). 20+30+0+5+0+10 = 65.

Wati 55

Read with the hosted lines. status.wati.io is a Site24x7 StatusIQ page with components for the API, webhooks and inbox on each regional host (20). Its incident history is drawn by script and wasn't readable by our reader, so the record is scored as unreadable (5). Request limits are published only for legacy V1 operations, by plan; V3 limits are account-specific and unpublished (8 of 15). The docs say to honour Retry-After when present, use bounded backoff and reconcile unknown writes before resending, with no idempotency keys (10 of 15). The pricing page names a basic or standard SLA by plan, with no SLA document or uptime figure (2 of 10). The V3 API is the documented default (10). 20 + 5 + 8 + 10 + 2 + 10 = 55.

ClickSend SMS API + MCP 30

HTTP Basic auth with the account username and one API key, and subaccounts get their own keys. The MCP server still writes the full request options, the Basic Authorization header included, to stderr on every call (repository unchanged since 11 August 2026), and MCP hosts keep stderr in log files (10 of 30). No read-only mode or confirmation before sends. Subaccounts give some separation (5 of 20). Inbound replies and SMS history are untrusted text returned straight to the model, with no injection guidance (0 of 15). SMS history and statistics by API (8 of 15). The security page now loads and names only AWS's certifications. ClickSend's footer links Sinch's trust centre for ClickSend, which gives security@sinch.com to report a vulnerability and posts dated vulnerability notes. Its ISO 27001 and SOC 2 badges "may apply to specific products" and aren't stated for ClickSend, and no security.txt (404) or bug bounty was found, so a reporting route with no acknowledgement time (7). 10+5+0+8+7 = 30.

Wati 40

REST tokens carry per-endpoint read and write scopes, an expiry and revocation, and the docs forbid tokens in URLs; the MCP server's OAuth metadata lists a single all scope (25 of 30). Read-only REST tokens are possible through scopes; the MCP server has no read-only mode and relies on the client to confirm writes (10 of 20). Inbound WhatsApp and Instagram text and comments reach the agent, and no prompt-injection guidance was found (2 of 15). No operator request log found in the docs (3 of 15). The trust centre answered 403, security.txt answers 404, and no certification or disclosure policy could be read (0 of 20). 25 + 10 + 2 + 3 + 0 = 40.