WhatsApp MCP Server: The Community Options, the Ban Risk, and the Official Path

There is no official WhatsApp MCP server from Meta, and the most popular community option is open about its mechanism but silent about its biggest risk: it works by puppeteering an unofficial WhatsApp Web bridge, which violates WhatsApp's terms of service and has a documented history of getting numbers banned, sometimes permanently. That is the honest landscape in one sentence. This guide maps it properly: what the community servers actually do, what Meta's policies say in plain language, the one legitimate route for connecting AI to WhatsApp, and how teams get a WhatsApp inbox their AI can work in without gambling the business number.

Your options at a glance

Option	How it connects	Ban risk	Best for
lharries-lineage bridges	Unofficial WhatsApp Web bridge, QR link	Real and documented	Personal experiments that accept the risk
Cloud API wrappers	Official Business Platform	None when compliant	Developers building on the sanctioned rails
Drag's official server	Official Business Platform, WhatsApp inbox beside Gmail	None, official path end to end	Teams working customer WhatsApp threads

The middle column is the whole decision. Everything below explains why.

The community WhatsApp MCP servers, and the bridge problem

The reference implementation this search surfaces, by far the most starred, connects to WhatsApp by emulating the WhatsApp Web client through an unofficial bridge library. It works, and its documentation is candid about the mechanism and about the prompt-injection risk of wiring AI into private messages. What it never mentions is the consequence that matters most: unofficial clients sit outside WhatsApp's terms, Meta actively detects them, and bans of connected numbers are a documented outcome rather than a theoretical one. For a personal account and a curious weekend, that is a risk someone might knowingly take. For a business number your customers message, it is a single point of failure with no guaranteed way back. A second family of community servers wraps the official Cloud API instead, which changes the risk entirely, and is the pattern worth looking for if you evaluate any of them.

Named, with the evidence current as of July 2026. The reference implementation is lharries/whatsapp-mcp, at roughly 5,900 stars the most-starred WhatsApp MCP server by an order of magnitude. It pairs a Go bridge built on the whatsmeow library with a Python MCP server: you link it to your account by scanning a QR code as if adding a WhatsApp Web device, your message history syncs into a local database, and the agent reads and sends through the bridge. Its README is upfront that it connects to your personal account through the Web multidevice interface, and it carries a prompt-injection warning; it says nothing about terms of service or bans. The original has not seen a commit in a year; the actively maintained continuation is the verygoodplugins fork, with commits as recent as this week. The ban evidence sits one level down, in the bridge library's own issue tracker, where users report account-at-risk warnings and bans on numbers running unofficial clients, including low-volume, reply-only use. On the other side of the line, wrappers around the official Cloud API exist, such as networkerman/whatsapp-cloud-api-mcp-server, far smaller and less discovered, but built on the sanctioned platform.

Telling the families apart takes one look at the setup instructions. If a server asks you to scan a QR code, it is impersonating a linked device on your personal account: that is the bridge family, whatever the README calls it. If it asks for a Cloud API access token and a phone number ID, and its send tools distinguish free-form messages from approved templates, it is riding the official platform. The QR code is the tell, because Meta's API has no QR codes in it; only the reverse-engineered Web protocol does.

What Meta actually permits

Meta's rules draw one line that matters here: automation must go through the WhatsApp Business Platform, the official Cloud API, not through reverse-engineered clients. Inside that line, the platform has its own grammar: business-initiated conversations use pre-approved message templates, free-form replies live inside the 24-hour customer service window after a customer messages you, and the API neither reads QR codes nor pretends to be a phone. Outside that line, detection means warnings, then bans, and WhatsApp bans attach to the number. Any MCP server, community or commercial, is legitimate exactly to the degree it rides the official API.

The receipts, from Meta's own pages. WhatsApp's help center states that unauthorized automated or bulk messaging violates its terms and leads to account bans. The Business Terms prohibit bypassing or circumventing the measures WhatsApp employs to prevent or limit access, and reserve Meta's right to limit, throttle, suspend, or terminate accounts that breach them. The Business Messaging Policy is where the grammar lives: outside the 24-hour customer service window, only approved message templates may be sent; inside it, free-form replies are allowed, and automation is permitted provided there are prompt, clear escalation paths to a human. And the platform's enforcement documentation describes the ladder: warnings and feature limits first, then permanent disablement from the Business Platform for businesses that do not change course.

For an AI agent, those rules translate cleanly. Inside the 24-hour window that opens when a customer messages you, the agent can draft and send real replies, which covers almost all of support work. Outside the window, it reaches for an approved template rather than free text. And because the rules are enforced at the API, a server built on the official platform cannot accidentally break them; the platform simply refuses the message. That is what compliance by construction looks like, and it is the exact opposite of a bridge that will send anything, anywhere, until the number gets flagged.

The governed path: a WhatsApp inbox your AI can work in

For teams, the practical question is rarely "how do I script WhatsApp" and almost always "how does my team, and increasingly my AI, work the WhatsApp conversations customers send us." That is a shared inbox problem, and it is the shape Drag solves on the official rails: your WhatsApp Business number connects through the sanctioned platform, conversations land as cards next to the team's email in Gmail, templates and the 24-hour window work the way Meta designed them to, and the whole surface, WhatsApp threads included, is manageable from Claude or ChatGPT through Drag's official MCP server. To our knowledge it is the first Gmail and WhatsApp shared inbox you can run from an AI client end to end, and, unlike the bridge servers, nothing about it puts the number at risk, because there is nothing unofficial in the chain. The broader argument, why every serious support tool is growing one of these servers, is the case our guide to MCP in support tools makes in full. The server itself is public: it ships on npm as @dragapp/mcp-server with the source on GitHub, and it is listed on the public MCP registries.

In practice, working WhatsApp from Claude through the official path looks like this:

Getting connected, briefly

The bridge servers install locally and link by QR code like WhatsApp Web, which is exactly the mechanism Meta's terms prohibit automating. The official path runs through WhatsApp Business Platform onboarding: a verified business, a registered number, and then the API, which is what Drag handles for you, connect the Business number, no API configuration, and the WhatsApp inbox appears beside the team's Gmail with the MCP server covering both. Setup details live in our connection guide.

Email has the same question with a gentler answer; our Gmail MCP server guide covers it.