If you have already decided you want Claude (or Cursor, or any MCP client) talking to WhatsApp, the next question is the hard one: which server do you actually install? Search "WhatsApp MCP server" and you get a dozen GitHub repos, an official-API option that needs a Meta Business account, and a few hosted services. They are not interchangeable. They differ on the one thing that matters most, which is how they connect to WhatsApp, and that single choice drives your setup effort, your reliability, and your account-ban risk.
This is a decision guide, not an explainer. If you are still asking "what is a WhatsApp MCP server in the first place," read our primer on WhatsApp MCP first, then come back. Here we assume you know the concept and you want a recommendation.
What a WhatsApp MCP server is (the 30-second version)
A WhatsApp MCP server is a small program that exposes WhatsApp actions (read a chat, send a message, look up a contact) as tools an AI model can call through the Model Context Protocol, the open standard Anthropic introduced in late 2024. You register the server once, and your AI client can then read and operate WhatsApp on your behalf.
That is the whole idea. The interesting part, and the reason this comparison exists, is that every server reaches WhatsApp through one of three transports, and they carry very different trade-offs. The rest of this article is about telling them apart and picking the right one.
How we evaluated
We scored the real, publicly available options on six criteria. None of them is a single winner; the right pick depends on which criteria you weight.
- Setup difficulty. Can a non-developer install it, or does it need Go, Python, a build step, and credential wrangling?
- Hosted vs self-hosted. Does someone run and keep it alive for you, or is uptime your problem?
- Reliability. Single laptop process that dies when you close your terminal, or a managed service with reconnect logic?
- Multi-device / multi-number. Personal number only, or can it scale to business numbers and teams?
- Official-API compliance and ban-risk. Does it use Meta's official Cloud API, or does it reverse-engineer the WhatsApp Web protocol (which violates WhatsApp's Terms of Service and carries real account-ban risk)?
- Capabilities. Read-only? Send? Schedule, templates, campaigns, groups?
The transport question (criterion 5) deserves a plain statement up front, because it is the most misunderstood. There are three families:
- Official Cloud API servers talk to Meta's WhatsApp Business Platform Graph API. Compliant, no ban-risk for legitimate use, but you need a Meta Business account, a verified number, and you live inside the template-and-session-window rules.
- Unofficial WhatsApp Web automation servers drive your personal account through reverse-engineered libraries such as
whatsmeow(Go) or Baileys (TypeScript). Two-minute setup against your own number, full personal-chat access, but using unauthorized third-party automation violates WhatsApp's Terms of Service and can get a number temporarily or permanently banned. - Hosted services that run an unofficial engine for you. Same transport family as the second group, but the reconnect logic, infrastructure, and session management are someone else's job.
We are calling that out honestly for every option below, including ours.
The comparison table
| Server | Transport | Hosted? | Setup | Capabilities | Ban-risk |
|---|---|---|---|---|---|
Blueticks MCP (@blueticks/mcp) | Unofficial wa-web (managed engine) | Yes (hosted) | ~2 min, npx, no build | Read, send, schedule, groups, audiences, campaigns | Same family as wa-web tools; managed to behave like a human session |
| lharries/whatsapp-mcp | Unofficial wa-web (whatsmeow, Go) | No (self-host) | High: Go bridge + Python server + QR | Read, search, send text/media/audio, download media (~12 tools) | Personal-number automation, ToS-violating |
| jlucaso1/whatsapp-mcp-ts | Unofficial wa-web (Baileys, TS) | No (self-host) | Medium: single Node process + QR | Read, search, list chats, message context, send text (6 tools) | Personal-number automation, ToS-violating |
| FelixIsaac/whatsapp-mcp-extended | Unofficial wa-web (whatsmeow, fork) | No (self-host) | High: same as lharries | up to 41 tools (reactions, groups, polls, presence, newsletters) | Personal-number automation, ToS-violating |
| networkerman/whatsapp-cloud-api-mcp-server | Official Meta Cloud API | No (self-host) | High: Meta Business account + tokens + Python | 50+ tools: messaging, templates, media, flows, analytics | Compliant; lowest ban-risk for legitimate use |
A note on fairness: the open-source projects are genuinely good software, actively used, and free. The table is not a ranking from best to worst. It is a map of trade-offs. A developer who wants local control will read it top to bottom and pick differently than an operator who never wants to see a terminal.
Walkthrough of the main options
The official path: Cloud API servers
If compliance is non-negotiable, this is the family to use. networkerman/whatsapp-cloud-api-mcp-server is a Python MCP server built from Meta's official WhatsApp Cloud API Postman collection, exposing 50-plus tools across messaging, template management, media, WhatsApp Flows, and analytics. Because it rides the official Graph API, it carries no ban-risk for legitimate business use, and it is the right choice if you are sending at scale to customers.
The cost is real, though. You need a Meta Business account, a verified phone number, an access token, a Phone Number ID, and a WABA ID before you write a single prompt. You also inherit the Cloud API's rules: outbound messages to people outside a 24-hour customer-service window must use pre-approved templates, and there are per-message fees. This is a business-messaging tool wearing an MCP coat, not a "read my personal chats" tool. Other servers in this family exist (for example, ones offering 50-plus tools with API-key auth and webhook signature verification), and they share the same profile: compliant, capable, and heavier to stand up.
The open-source personal-account servers
The most-starred WhatsApp MCP project is lharries/whatsapp-mcp. It is a two-part system: a Go bridge using the whatsmeow library (the unofficial WhatsApp Web multi-device protocol) that authenticates by QR code and stores your history in a local SQLite database, plus a Python MCP server exposing roughly a dozen tools (search_contacts, list_messages, send_message, send_file, send_audio_message, download_media, and more). Everything stays on your machine and only reaches the AI when a tool is explicitly called, which is a genuinely good privacy property. The price is setup: you run two processes, install both Go and Python toolchains, and keep the bridge alive yourself.
jlucaso1/whatsapp-mcp-ts is the lighter cousin. It is a single TypeScript Node.js process built on Baileys (also unofficial WhatsApp Web multi-device), bundling the WhatsApp connection, SQLite storage, and MCP server together. It exposes six focused tools (search_contacts, list_messages, list_chats, get_chat, get_message_context, send_message). One process instead of two is a real simplification if you are comfortable in the Node ecosystem.
If you want maximum surface area, FelixIsaac/whatsapp-mcp-extended is a fork of lharries that pushes to up to 41 tools, adding reactions, richer group management, polls, presence, and newsletters. verygoodplugins/whatsapp-mcp is another actively maintained fork of the same whatsmeow-based codebase, created because the original had gone quiet. Both inherit the same transport and therefore the same ban-risk and the same self-host burden.
The honest summary for this whole family: free, local, flexible, and they read your real personal chats, which the official Cloud API cannot do. But they all drive your own number through reverse-engineered automation, they all require you to keep a process running, and they all carry account-ban risk (more on that below).
Blueticks MCP: the hosted option
Blueticks publishes a hosted MCP server, @blueticks/mcp, aimed at people who want the personal-number capability without the self-hosting. You connect it by adding one server entry to your Claude config that runs npx -y @blueticks/mcp with an API key, and the package pulls itself on first run, so there is no repo to clone, no Go or Python toolchain, and no bridge to babysit. The WhatsApp session itself runs on Blueticks' managed engine rather than on your laptop, so it reconnects on its own and survives you closing your terminal.
Being honest about transport: Blueticks operates an unofficial WhatsApp Web automation engine, the same transport family as the open-source personal-account servers above, not the official Cloud API. What you are paying for is that Blueticks runs and maintains that engine as a managed, human-like session instead of leaving it on your machine. The capability set leans toward operators: alongside read and send, it covers scheduling, groups, reusable audiences with per-contact variables, and campaigns, which the bare open-source servers do not. It is also the only zero-terminal option here. Blueticks also ships a Chrome extension if you prefer the in-browser product, but the MCP is the path for driving WhatsApp from an AI client.
Hosted vs self-hosted: the real decision
Strip away the brand names and the choice is mostly this one axis.
Self-host (any of the open-source servers, or a Cloud API server you deploy) when you want full control of your data, you are comfortable keeping a process alive, and "it runs on my machine and I can read the SQLite file" is a feature, not a chore. The trade-off is operational: the bridge dies when your laptop sleeps, reconnect is your problem, and a WhatsApp protocol change can break things until someone patches the library.
Hosted (Blueticks, or a managed Cloud API provider) when uptime is not your job and you would rather not learn whatsmeow. The trade-off is trust and recurring cost: your session runs on someone else's infrastructure, and you are betting on their reliability instead of your own.
There is no universally correct answer. A developer building a side project will rationally self-host. An operator who needs their assistant to still be connected at 7am without having touched a terminal will rationally pay for hosted.
Compliance and ban-risk: read this before you pick
This is the criterion most roundups skip, and it is the one most likely to cost you a phone number.
Using unauthorized third-party software to automate or bulk-send on WhatsApp violates WhatsApp's Terms of Service, and Meta enforces it. Every server in this comparison that uses whatsmeow or Baileys (lharries, jlucaso1, the extended and verygoodplugins forks, and Blueticks' managed engine) is in that category. Reported ban timelines for reverse-engineered protocol tools commonly land in the 2-to-8-week range once a number trips detection, and the risk scales sharply with behavior: a setup that only reads and replies to existing conversations is far lower risk than one blasting proactive first-contact messages to people who never saved your number. Detection signals include high message volume in short windows, messaging strangers who then block or report you, and the technical fingerprints of scripted Web sessions.
The only structurally zero-risk path is the official Cloud API (the networkerman server and its family), used within Meta's rules. That is the honest answer, and it is why a serious business sending to customers at scale should default to it despite the heavier setup.
Where does that leave the unofficial options? They are legitimately useful for personal and light-touch use, where the value (Claude reading your real chats and drafting replies you approve) is high and the volume is low. If you go this route, behave like a human: do not bulk-blast cold contacts, keep volumes sane, and understand you are accepting a non-zero risk. A managed engine like Blueticks' is built to keep the session looking like a normal human session, which mitigates but does not eliminate that risk. No unofficial tool, hosted or self-hosted, can promise zero ban-risk, and any that does is overclaiming.
Which to pick for which use case
You are a developer who wants local control and free. Start with lharries/whatsapp-mcp for the largest community and tool set, or jlucaso1/whatsapp-mcp-ts if you would rather run one TypeScript process than a Go bridge plus a Python server. Self-host, keep volumes modest, accept the ToS reality.
You are an AI power user who wants the most tools. FelixIsaac/whatsapp-mcp-extended gives you up to 41 tools (reactions, polls, presence, newsletters) on the same whatsmeow base, if you are willing to self-host.
You are a business sending to customers at scale, and compliance is mandatory. Use an official Cloud API server such as networkerman/whatsapp-cloud-api-mcp-server. Budget for the Meta Business account, verification, and the template-and-fees model. This is the only no-ban-risk path.
You are non-technical, or you just do not want to run infrastructure. Use Blueticks MCP. It is the only option here you can install without a build step and that stays connected without you keeping a process alive, and it adds scheduling, audiences, and campaigns on top of read/send. Understand it uses an unofficial managed engine, not the Cloud API, and keep your sending human-paced.
FAQ
Is there a single best WhatsApp MCP server? No, and any roundup that names one is hiding the trade-offs. The best server for a developer (a free self-hosted open-source project) is different from the best for a compliance-bound business (an official Cloud API server) and different again from the best for a non-technical operator (a hosted service). Match the server to your constraints.
Which WhatsApp MCP servers use the official WhatsApp API? The Cloud API family, such as networkerman/whatsapp-cloud-api-mcp-server, talks to Meta's official WhatsApp Business Platform Graph API. The popular personal-account projects (lharries, jlucaso1, their forks) and Blueticks' managed engine all use the unofficial WhatsApp Web protocol instead.
Can a WhatsApp MCP server get my number banned? If it uses unofficial automation (whatsmeow, Baileys), yes, that is possible, because it violates WhatsApp's Terms of Service. Risk rises steeply with cold outreach and high volume and is low for read-and-reply use on existing chats. The official Cloud API does not carry this risk when used within Meta's rules.
Can the official Cloud API read my personal WhatsApp chats? No. The Cloud API is for business numbers and messaging customers; it cannot read your existing personal conversations. Only the unofficial WhatsApp Web servers (and hosted services built on them) can read your real personal chat history.
What is the easiest WhatsApp MCP server to set up?
A hosted one with no build step. Blueticks MCP connects via a single npx entry in your Claude config and runs the WhatsApp session on its own infrastructure, so there is nothing to clone, compile, or keep alive. The self-hosted open-source servers require toolchains, a QR-code login, and a process you maintain.
Do I need to keep my computer on for a self-hosted server? For the open-source self-hosted options, effectively yes: the bridge or Node process has to be running for the AI to reach WhatsApp, and it disconnects when your machine sleeps. Hosted services run the session elsewhere, so they stay connected regardless.
Blueticks MCP: the zero-setup hosted option
If you read the use-case section and landed on "non-technical" or "I just do not want to run infrastructure," Blueticks MCP is built for exactly that. It is the only option in this comparison you install without a toolchain or a build step: one npx -y @blueticks/mcp entry in your Claude config with an API key, and Claude can read your chats, draft replies you approve, and send or schedule from your own number, with the WhatsApp session running on Blueticks' managed engine instead of your laptop.
We have been straight about the trade-off: it uses an unofficial managed WhatsApp Web engine, not the official Cloud API, so keep your sending human-paced. In exchange you get zero setup, a session that stays connected on its own, and operator features (scheduling, reusable audiences, campaigns) the bare open-source servers do not include. If that matches how you work, start with the WhatsApp MCP setup guide and connect it in about two minutes.
