WhatsApp MCP server. Four ways one exists, and how to pick the right one.

The protocol is identical. The mechanism is everything.

MCP is a thin envelope. The host forks a child process, asks tools/list, and then sends tools/call for each invocation. That part is boring and the same across every server you have ever seen. What changes between implementations is what the server actually does when send_message arrives. The four common answers, in order from most-corporate to most-OS-native:

Three things decide which row is right for your project: who owns the auth (you, Meta, or the desktop app), who owns the rate-limit-and-ban risk, and which platforms you need to support. If you cannot tolerate the MCP holding credentials, the bottom row is the only one where it does not.

What a Business Cloud API server looks like on the wire

Most public “WhatsApp MCP” listings on directories like mcpmarket and Zapier are this. The MCP is a thin shell over an HTTPS POST to graph.facebook.com/v17.0/<phone_number_id>/messages. The MCP holds a long-lived Meta access token. The send is asynchronous: you get a queued message ID immediately, and the actual “delivered” signal arrives later as a webhook POST to a public HTTPS endpoint you host.

Three honest consequences. First, you need a Meta developer account and a verified WhatsApp Business Account, which takes one to five business days. Second, you can only send freeform messages inside the 24-hour customer-service window after a user messages you; outside that window, every send must be a Meta-approved template. Third, every conversation is metered by country and category. Right tool if you are running B2B marketing to opted-in lists. Wrong tool if you want Claude to nudge your friend about lunch.

What a whatsmeow / web-multidevice server looks like

The most popular GitHub result for “WhatsApp MCP” is lharries/whatsapp-mcp. It embeds a Go bridge built on the whatsmeow library, which speaks the reverse-engineered multidevice protocol the official WhatsApp Web client uses. The MCP scans a QR code at first launch and registers itself as one of your linked devices. It then keeps its own session alive, stores incoming messages in a local SQLite database, and the MCP tools mostly query that DB.

Three honest consequences. First, no Meta developer account is involved, so you get freeform reach to anyone you can already message. Second, the MCP IS your auth: if the bridge process dies permanently or you wipe its session, the linked-device slot is gone and you re-pair. Third, Meta has historically suspended accounts that hammer the web-multidevice protocol in a way that looks like a bot, so high-volume use is a real risk vector. Right tool on Linux or Windows, or when you genuinely need to grep across years of personal message history. Wrong tool if you want to avoid holding any kind of WhatsApp-side auth in the MCP process.

What a headless WhatsApp Web server looks like

A handful of community servers drive web.whatsapp.com inside a Playwright or Puppeteer Chromium. From WhatsApp’s point of view this is identical to the whatsmeow path: another linked device, another web session. From your point of view it is strictly worse, because in addition to the linked-device footprint you also have a browser process to keep alive and a DOM full of data-testid selectors that change every time WhatsApp Web ships. Most of the entries on awesome-mcp-server style directories that claim a “web-based” WhatsApp MCP are this. If a selector breaks at 11pm, your MCP is silently broken until you redeploy.

Right tool for a hack-day demo. Wrong tool for anything that has to keep working without weekly attention.

What a macOS accessibility server looks like

The bottom row of the comparison table is the one this site is about. It does not replace Meta’s API with another API. It replaces the API call with a process binding plus a UI-tree walk. The MCP looks up the running net.whatsapp.WhatsApp process by bundle id, gets its PID, calls AXUIElementCreateApplication, and walks the same accessibility tree VoiceOver does. There is no access token, no QR pair inside the MCP, no linked-device slot consumed. The auth is whatever the desktop app is signed in as.

Worth comparing the two diagrams side by side. The Business API path has a network hop, an async webhook, and a token. The accessibility path has a pid, a tree walk, two CGEvents, and a second tree walk to verify. No network, no token, no webhook. The config env block reflects that:

That env: {} is not a placeholder. The MCP layer carries zero secrets. If you check this config into a backup you are not backing up a Meta token, because there is not one.

The detail no other WhatsApp MCP server documents

Every MCP server I have read returns success for send_message as soon as the underlying call accepts the payload. The Business API path returns the moment graph.facebook.com returns 200 with a message ID. The whatsmeow path returns the moment the web-multidevice handshake acks. Neither one reads the conversation back to confirm the message bubble actually rendered. If WhatsApp silently drops or queues your message, the model is told the send succeeded.

The macOS server does it differently. After it pastes the text and posts a Return CGEvent, it re-walks the accessibility tree of the WhatsApp window. WhatsApp Catalyst exposes every outgoing message as an AXGenericElement whose description is the literal string "Your message, <text>, 12:04 PM". The server filters for that prefix, strips the timestamp with a regex, normalizes whitespace and case, and prefix-matches the text it just sent. Only if that match holds does the tool return verified: true. Otherwise it returns verified: false with a warning containing the last sent bubble it actually found.

Why this matters. An LLM that called whatsapp_send_message and got back verified: true can move on; an LLM that got verified: false knows it has to retry, re-verify the active chat, or tell the user. That is a real signal, not a 200 OK from a queue. Worth grepping the source of whatever WhatsApp MCP server you are considering for “verified” before you trust its success-return at face value.

The 11 tools the macOS server exposes

Defined in setupAndStartServer (main.swift line 990). Each tool below is a real Tool(name:description:inputSchema:) registration, not a marketing list:

Installing the macOS server, end to end

Two commands and a config edit. No portal, no verification email, no phone code. The postinstall step compiles the Swift binary, that is the only build step.

How to choose between the four

A short decision rubric, in plain language, with no marketing varnish:

• Pick Business Cloud API if your use case is opted-in broadcasts, verified-sender badge, or compliance with a published WhatsApp business policy. You are willing to wait for verification and pay per conversation.
• Pick whatsmeow / web-multidevice if you are on Linux or Windows, want freeform personal reach, and accept that the MCP itself holds your session and is your linked device. You accept the (small but real) risk of account suspension if usage looks botty.
• Pick headless WhatsApp Web only for a throwaway demo. It is the strictly-worse cousin of whatsmeow.
• Pick macOS accessibility if you are already on macOS with WhatsApp Desktop installed, want freeform personal reach without burning a linked-device slot, and want the MCP process to hold no credentials at all. Accept that this is the only path that needs you to keep the desktop app running and to grant Accessibility to the host once.