Manychat automates WhatsApp through Meta. There is another path.

No. Manychat, Wati, Interakt, Twilio and every other platform you will find at the top of a search for WhatsApp automation are skins on Meta's WhatsApp Business API. They exist because Meta does not let you send messages through the API without a certified platform or your own approved app. That path is correct when your goal is outbound broadcasting to opted-in customers. It is the wrong tool when your goal is to automate the account you personally use to talk to people, because the Business API cannot send as your personal number and will never be able to. The alternative class of automation is a local agent that drives the WhatsApp Desktop app on your own machine through operating-system accessibility APIs, the way assistive tech drives any other app. whatsapp-mcp-macos is an example. It binds to the bundle id net.whatsapp.WhatsApp, walks the accessibility tree of the running WhatsApp window, and types into the compose field on your behalf.

Everything the Meta Business API layer provides, because you are no longer using it. You lose the ability to initiate conversations with strangers who have not messaged you first, because on your personal account you never had that ability. You lose the flow builder dashboard, campaign analytics, segment tagging, and template management, because there is no middleware doing those things. You lose horizontal scale: a local agent runs on one Mac at a time and cannot send a thousand messages per minute even if you wanted it to. You also lose the compliance story you would present to Meta, because you are not sending through Meta at all, you are acting as yourself. The upside is that every one of those losses corresponds to a category of setup, approval, or fee that no longer applies.

No. The server does not speak HTTP to Meta at any point. It binds to the WhatsApp Desktop macOS Catalyst app via its bundle id, net.whatsapp.WhatsApp, and drives it through AXUIElement calls. There is no API key, no access token, and no env var to set: the server takes zero environment variables at startup. The only thing it needs is the operating system's Accessibility permission, and that permission is granted to the host process (Claude Code, Cursor, or whichever MCP host is forking it), not to the binary itself, because on macOS the TCC database attributes the privileged AX call to the responsible parent.

There is no 24-hour window for a local agent because the 24-hour window is a Business API construct. Meta enforces it at the API layer: a business cannot freeform-message a user more than 24 hours after the user's last inbound without using an approved template. A local agent is not speaking to the API. It is typing into the same compose field you would type into yourself, which means the only rule that applies is the one WhatsApp applies to you, the human, when you open the app and send a message. You can reply to your mom three days later, and so can an agent acting on your account.

By reading the accessibility tree back after the Return key is pressed and comparing. Inside handleSendMessage (Sources/WhatsAppMCP/main.swift, lines 887 through 958) the server pastes the message into the compose field, posts a Return CGEvent, waits 1.0 second for the UI to settle, then re-traverses the AX tree and searches for the newest AXGenericElement whose description string begins with the literal prefix Your message, . If that element exists and its embedded text contains the message that was pasted, the tool returns verified: true. If it does not, the tool returns verified: false along with whatever the last sent message was, so the caller can decide whether to retry. This is why a send returns a strict boolean rather than an optimistic success: the verification round-trip is part of the contract.

It is the AX messaging timeout for the WhatsApp Desktop application element. At main.swift line 120 the server calls AXUIElementSetMessagingTimeout(appElement, 5.0), which tells the accessibility framework that any call made through this element (a request for children, a value fetch, a click post) has at most 5.0 seconds to complete before it errors out. That ceiling applies to every tool that touches the UI: search, open, read, send, navigate. It is hardcoded. There is no config flag to lengthen it. In practice a well-behaved WhatsApp window responds to an AX traversal in a few hundred milliseconds, so the ceiling only trips when the window is minimised, offscreen, or still loading the sidebar. If you see timeouts, check the window state before you blame the server.

No. The server does not have a create-new-chat tool. The whatsapp_search tool searches your existing chats and contacts, and whatsapp_open_chat clicks the Nth search result to open a chat that was already in the sidebar. If a number is not already in your WhatsApp, the agent cannot reach them. This is a property of the accessibility approach rather than a limitation of the implementation: to message a new number on WhatsApp, you start a new chat from the Desktop UI, which is a flow a future tool could implement, but today the tool surface is intentionally scoped to conversations the user is already part of. That scoping is also what keeps the automation safe for personal use.

Eleven, defined at main.swift line 1110 where the array [statusTool, startTool, quitTool, getActiveChatTool, listChatsTool, searchTool, openChatTool, scrollSearchTool, readMessagesTool, sendMessageTool, navigateTool] is assembled and passed to the server. The server logs this on boot with the stderr line setupAndStartServer: defined 11 tools. The split is five inspection tools (status, get_active_chat, list_chats, read_messages, navigate state), four navigation tools (start, quit, search, open_chat, scroll_search), and two write tools (send_message and the implicit send inside status checks). A Manychat flow builder exposes hundreds of dashboard affordances. This is deliberately a smaller surface because an AI host does not need a dashboard, it needs primitives it can compose in a turn.

For different jobs. If your business is growth-mode e-commerce sending order confirmations and abandoned-cart templates to thousands of opted-in customers, Manychat replaces nothing for you; keep it and do not look at the local path. If you run a small practice, a creator studio, or a founder-led sales motion and your WhatsApp is the front door for real human inbound, Manychat is the wrong shape: you do not have a Meta-approved business number and you do not want opt-in walls between you and the person who just referred a friend. For that workflow the local agent is the right tool and you will not need Manychat at all. Some teams run both, on separate numbers, for exactly that reason.

A Mac running macOS 13 or later, WhatsApp Desktop installed and signed in, an MCP-aware host (Claude Code, Cursor, or another client that reads ~/.claude.json style config), Node 18 or later to run the npm install which compiles Swift via the postinstall, and one minute in System Settings to grant Accessibility to the host. Total time from zero to first verified send is roughly five minutes, and the vast majority of that is the one-time Swift build. There is no account to create, no phone number to register, no template to write.