WhatsApp desktop automation vs the Cloud API: pick by throughput, not features.

From reading the actual send code. The function handleSendMessage in Sources/WhatsAppMCP/main.swift performs four explicit Thread.sleep calls totaling 1.9 seconds (0.3s after app activation, 0.3s after clicking the compose field, 0.3s after Cmd+V paste, 1.0s after pressing Return), plus two full traversals of the WhatsApp accessibility tree (the pre-send compose-field lookup and the post-send verification walk). Each traversal walks the Catalyst app's AX tree end to end and parses every AXGenericElement, typically 150-300ms each on a recent Mac. Add the keystroke and clipboard time and one verified send lands at roughly 3.5-5 seconds, depending on chat length and machine. At that cadence the steady-state ceiling is around 12-17 messages per minute. The 15/min number rounds the middle of that range. It is a ceiling for steady state, not a burst limit.

Because the desktop app does not return one. The accessibility framework lets you click and type into another app but does not expose 'message sent' as an event you can subscribe to. The closest signal is the bubble itself appearing in the chat list, which is what a human looks at. So the server simulates that: 1.0 second after Return, it walks the accessibility tree again, collects every AXGenericElement, and looks for one whose description begins with the literal string 'Your message, '. WhatsApp's Catalyst client uses that prefix on every outgoing bubble. Match against the text we typed returns verified:true. Mismatch returns verified:false with the visible bubble in a warning field. This is the same signal the Cloud API ultimately exposes via webhooks (status: delivered), just collected from the client side instead.

Yes, but only by adding hardware. The bottleneck is the WhatsApp window itself, which is a singleton UI on one OS user session. You cannot drive two chats in parallel inside one app because the compose field has one focus. The way to scale horizontally is one Mac per identity: every Mac runs its own WhatsApp app signed in to its own account, with its own MCP server. Throughput multiplies linearly with hardware. The reason most teams do not go this route past two or three Macs is operational cost; at that point the Cloud API is cheaper end-to-end even when you factor in BSP markup.

For the HTTP ACK, yes, comfortably. The Graph API returns within roughly 300ms for a valid request, and you get a message ID immediately. For the true 'message delivered' event, no. Webhooks for sent / delivered / read are async and arrive when the recipient's device acknowledges. Sent typically lands in 1-3 seconds. Delivered depends on the recipient's network. Read depends on the recipient looking at their phone. If your bar is 'I got Meta to accept this request', the Cloud API is faster than desktop automation by ~10x. If your bar is 'I know the message bubble is on the recipient's screen', the two paths land roughly in the same wall-clock window and the desktop path is the only one that gives you a synchronous answer.

That is a reasonable shape and the two MCP entries can coexist in one config. A Cloud-API-wrapping MCP server (HTTP transport) handles outbound to opted-in users; the local desktop server (stdio) reads the personal inbox, drafts replies, and sends one-to-one messages from the personal account. The agent picks based on which account should send. The split is clean because the sending identities are distinct: the Cloud-API number is a verified business number that does not exist in the consumer app, and the desktop number is your personal account that does not exist in Business Manager. There is no overlap to worry about.

Meta moved from conversation-based pricing to per-message pricing on November 1, 2025. Marketing templates are billed by destination country and category. Headline ranges from Meta's pricing documentation: marketing templates roughly $0.025 (India) to $0.1365 (Germany) per message, utility templates lower (often near zero in some markets through 2025-2026 promo windows), authentication templates separately priced. Service messages, meaning replies inside the recipient's 24-hour service window, remain free. BSPs add markup on top. Check the current rates at https://developers.facebook.com/docs/whatsapp/pricing before doing capacity math; the numbers move.

It uses two sanctioned surfaces: the official WhatsApp desktop app and the macOS Accessibility framework (the same surface VoiceOver uses). What gets accounts banned is the kind of activity, not the mechanism. A personal account using desktop automation to send the messages it would normally send, to people it would normally send them to, is the same as a human typing in the same app. A personal account using any automation, including desktop automation, to mass-message strangers or behave like a business, is the kind of activity that triggers consumer terms enforcement; it is also what the Business API exists for. Read the consumer terms at https://www.whatsapp.com/legal/terms-of-service before pushing volume.

Desktop automation as a category exists on every OS. WhatsApp has a desktop app on Windows and a web client that runs on Linux. The macOS-specific accessibility-driven approach this site documents does not port directly because the underlying APIs (AXUIElement on macOS, UI Automation on Windows, AT-SPI on Linux) are different and the WhatsApp Windows app exposes a different accessibility tree. If you are on Windows, the available paths are an open-source library that speaks the multi-device protocol (Baileys, whatsapp-web.js) or commercial WhatsApp-Web automation SaaS. The Cloud API is the same on every OS because it is a Meta-hosted HTTP endpoint; nothing on your side is OS-specific beyond a webhook server.

Plenty of products do both, on purpose. A small example: a consumer-facing service uses the Cloud API to send order updates from a verified business number, and the founder uses the desktop server on their own Mac to reply personally to high-touch inbound from their personal account. Same product, two sending identities, two MCP entries in the same agent config. The decision tree above is about a single message: who is sending, to whom, at what rate. Most products have more than one answer.

Those are a third architectural category: open-source clients that speak WhatsApp's multi-device protocol directly (Baileys) or drive whatsapp-web.com via Puppeteer (whatsapp-web.js). They are interesting when you want desktop-style flexibility without macOS-only hardware. The tradeoff is account-level: WhatsApp's anti-automation systems monitor the multi-device protocol and whatsapp-web.com closely, and accounts running these libraries do get banned, especially for outbound that looks bulk. Treat any account you operate this way as disposable. The desktop accessibility path avoids that surface because it drives the official client; the protocol traffic looks identical to a human user's.