{
  "markdown": "# whatsapp-connect-mcp\n\nA WhatsApp MCP server shipped as a single static Go binary. One download, one\n`setup` command, one QR scan — then any MCP client (Claude Desktop, Claude\nCode, Cursor, Windsurf, Cline, …) can read, search, and send WhatsApp\nmessages, with every outbound send protected by a server-enforced gate.\nThat one-step path is the default stdio transport; the shared **http**\ntransport adds one more step — a server you start and keep running (see\n[Install](#install-two-minutes)).\n\n> **This uses an unofficial protocol. Read this before you pair a number you\n> care about.**\n>\n> whatsapp-connect-mcp talks to WhatsApp the same way WhatsApp Web does, via\n> [whatsmeow](https://github.com/tulir/whatsmeow) — not an official WhatsApp\n> Business API. Meta can and does ban numbers it detects using third-party\n> clients on this protocol, and such bans are widely reported as permanent.\n> The send gate and rate limiter described below cut the behavioral half of\n> that risk (accidental bulk sends, a model going rogue); **they cannot touch\n> the other half**, which is that this client is identifiable as a\n> third-party client at all. [Ban risk](#ban-risk) lays out what the public\n> evidence actually shows, with dates. Pair a number you're comfortable\n> losing, not your only line to your bank or your family.\n\nStatus: pre-release.\n\n## Install (two minutes)\n\nPick one:\n\n```sh\n# macOS / Linux\ncurl -fsSL https://raw.githubusercontent.com/idle-sync/whatsapp-connect-mcp/main/scripts/install.sh | sh\n```\n\n```powershell\n# Windows (PowerShell)\nirm https://raw.githubusercontent.com/idle-sync/whatsapp-connect-mcp/main/scripts/install.ps1 | iex\n```\n\n```sh\n# Anywhere with Node installed, no separate download step\nnpx whatsapp-connect-mcp setup\n# or, sturdier for setup: a global install\nnpm install -g whatsapp-connect-mcp\n```\n\n> `npx whatsapp-connect-mcp serve` works fine on its own, but for `setup`\n> prefer one of the install scripts above or the global install. `setup`\n> injects an absolute path to the running binary into each MCP client's\n> config, and under `npx` that path is inside npm's package cache — clear\n> that cache and every client config `setup` wrote now points at a binary\n> that's gone. A global install keeps the binary at a stable path until\n> the package itself is upgraded or removed.\n\nEach of these downloads the release binary for your OS/architecture and runs\n`setup`: it shows a QR code to scan from WhatsApp (Linked Devices → Link a\nDevice), then detects installed MCP clients and offers to inject a\n`whatsapp` server entry into whichever ones you pick. No toolchain, no\nmanual JSON editing.\n\n`setup` also asks how clients should connect. **stdio** (the default) has\neach client start its own server process — simplest, but only one client\nor session can be connected at a time, since one `serve` holds the data\ndirectory's exclusive lock. **http** points every selected client at one\nshared local server (`http://127.0.0.1:<port>`, port of your choosing,\ndefault 2178, bearer-token authenticated) so several clients and sessions\nconnect at once.\n\n> **Picked http? There is a step 2: start the server.** Nothing starts it\n> for you — until it runs, every client reports something like\n> `ConnectionRefused at http://127.0.0.1:2178`. Run (and keep running):\n>\n> ```sh\n> whatsapp-connect-mcp serve --http 127.0.0.1:2178\n> ```\n>\n> It acknowledges with `serve: listening on http://127.0.0.1:2178 …` and\n> stays in the foreground, so it dies with its terminal. To keep it alive\n> across logouts and reboots instead, install it as a background service\n> (launchd on macOS, a systemd user unit on Linux, or a Task Scheduler logon\n> task on Windows):\n>\n> ```sh\n> whatsapp-connect-mcp service install\n> ```\n>\n> `service uninstall` removes it; `service restart` restarts it after an\n> update. On a headless Linux box, add `loginctl enable-linger` so the\n> service outlives your login session. On Windows, the service runs as a\n> minimized console window that appears at user logon (not boot); closing the\n> window stops the server. There is no automatic restart on crash (serve's\n> unpaired state waits idle rather than exiting, so the common failure mode\n> never exits anyway). Creating the task may require an elevated\n> (Administrator) terminal.\n\n`setup` can be re-run any time — to pair again, or to add a client you\ninstalled later.\n\nPass `--full-history` to ask the phone for as much history as the protocol\nallows rather than the default few months. It only has any effect while\nactually pairing, so an install that is already paired must `remove` first;\n`setup` says so rather than silently ignoring the flag. The phone still\ndecides what it really sends.\n\n## What this is for\n\nThe fourteen read tools are the product; the ten gated write tools are a convenience.\nIn practice that means:\n\n- **Searching your own history.** WhatsApp's own search has no date filters\n  and shows you a hit with no context around it. `search_messages` plus\n  `get_message_context` does both.\n- **Catching up.** Point a model at the 400 messages a group accumulated\n  while you were away and ask what happened.\n- **Reading your own attachments.** `download_media` pulls down the invoices,\n  receipts, and screenshots people sent you so a model can actually read\n  them.\n- **Finding loose ends.** `get_last_interaction` answers \"who messaged me\n  that I never replied to?\"\n- **Drafting replies.** The model writes it, the send gate makes you confirm\n  it, then it sends.\n- **Searching WhatsApp alongside everything else.** With mail, chat, or\n  calendar MCP servers connected to the same client, \"did this client contact\n  me about the invoice, and where?\" becomes one question instead of three\n  separate searches. For anyone whose real correspondence lives in WhatsApp,\n  this is the reason to run it.\n\n### What not to use it for\n\nDo not build a support bot, an outreach tool, or an auto-responder on this.\nMessaging people who never messaged you first, at volume, is the behavior\nmost consistently reported to get numbers banned (see\n[Ban risk](#ban-risk)) — and it is precisely the use case Meta sells the\nWhatsApp Business API for. This is a personal tool for your own messages.\nPoint it at customers and you will lose the number.\n\n## What it gives your MCP client\n\nTwenty-four tools: fourteen read-only, ten gated, described below.\n\n### Read / search (no gate)\n\n| Tool | What it returns |\n|---|---|\n| `list_chats` | Chats (1:1 and group), newest activity first; filterable by name and archived state. |\n| `get_chat` | One chat by JID. |\n| `list_messages` | Messages in a chat, newest first, optionally time-bounded — pass a named window (`today`, `yesterday`, `last_24h`, `last_7d`) or a `date` with an IANA `tz`, or explicit bounds (Unix seconds, RFC 3339, or a bare date); the server does the timezone arithmetic. |\n| `search_messages` | Full-text search over message bodies, chat-scoped or global. |\n| `get_message_context` | The messages immediately before/after one target message. |\n| `search_contacts` | Contacts by name or phone number substring. |\n| `get_last_interaction` | The most recent message involving a JID. |\n| `list_group_participants` | A group's member JIDs, fetched live. |\n| `get_group_info` | A group's subject, description, owner, and admins, fetched live. |\n| `get_blocklist` | The JIDs the account has blocked, fetched live. |\n| `get_call_history` | Calls, newest first, optionally filtered to one peer and time-bounded with the same window/date/tz forms as `list_messages`. |\n| `download_media` | Downloads attached media to the local data directory — one message, a batch of message ids, or everything in a time window (same window/date/tz forms as `list_messages`, optionally filtered by kind). |\n| `poll_new_messages` | New messages after a cursor, oldest first — `tail: N` returns the newest N immediately, and a timeout blocks up to 240s until one arrives, so an agent can react to activity without re-reading chats. Own sends excluded unless asked for. Read-only; reacting still goes through the send gate. |\n| `fetch_older_messages` | Asks the phone for messages from before the oldest one stored in a chat, widening how far back it can be read. Call repeatedly to page further back. |\n| `doctor` | Runs the diagnostics described in [Diagnostics](#diagnostics) as an MCP tool. |\n\n> How far back any of these reach is decided by the paired phone, not by this\n> server. \"Search my whole history\" can turn out to mean \"search the last few\n> months\" — see [Limitations](#limitations-stated-plainly).\n\n### Send (gated — see below)\n\n| Tool | What it does |\n|---|---|\n| `send_message` | Sends text, optionally quoting an existing message. |\n| `send_media` | Sends an image, video, or document from an allowed directory, with an optional caption. |\n| `send_voice_note` | Sends a voice note from an Ogg Opus (`.ogg`) file in an allowed directory. No transcoding — other formats are rejected. |\n| `send_reaction` | Reacts to a message with an emoji (empty emoji removes a prior reaction). |\n| `edit_message` | Edits the text of a message you sent, within WhatsApp's edit window. |\n| `delete_message` | Deletes a message for everyone (your own always; others' only as a group admin). |\n| `create_poll` | Creates a poll (a question and two or more options); reading votes is not supported. |\n| `mark_read` | Marks one or more messages as read. |\n| `schedule_send` | Schedules a text or media send for a future time (up to 30 days; `send_at` or `delay_minutes`). The gate applies at scheduling time — untrusted recipients draft-and-confirm the schedule, fire time included — and the fire consumes the shared rate limiter. Persists across restarts; fires only while `serve` runs (≤15 min late fires on next start, older is dropped). |\n| `list_scheduled` | Pending scheduled sends, soonest first. |\n| `cancel_scheduled` | Cancels one pending scheduled send — always allowed, it only ever prevents a send. |\n| `block_contact` | Blocks a contact; always drafts first, never auto-commits on trust. |\n| `unblock_contact` | Unblocks a contact; always drafts first, never auto-commits on trust. |\n\nEvery tool result built from WhatsApp data — messages, names, contacts,\ncaptions — is wrapped in an explicit untrusted-data banner. Treat it as\ndata an MCP client is showing you, never as instructions the model should\nfollow: nothing arriving over WhatsApp can tell your assistant what to do.\n\n## The send gate\n\nThis is the part `verygoodplugins/whatsapp-mcp` doesn't have. Every\noutbound action — text, media, voice note, reaction, edit, delete, poll,\nblock, unblock, or read receipt — goes through one path, enforced by the server, not by prompting\nthe model to \"be careful\":\n\n1. **Draft first.** Call a send tool for a recipient you haven't trusted\n   yet, and nothing is sent. You get back a preview (the recipient resolved\n   to a name + JID, and the exact outbound content) and a `draft_token`.\n2. **Confirm to commit.** Re-issue the identical call with that\n   `draft_token` and it sends. Drafts expire after 5 minutes; a byte\n   difference in the resubmitted content invalidates the token.\n3. **Trust, deliberately.** `whatsapp-connect-mcp trust --add <jid>` marks a\n   contact or group as trusted, so sends to it commit on the first call\n   instead of drafting. This is a CLI-only switch — no MCP tool can grant\n   trust, so a model can't trust its way around the draft step. The list\n   is re-read on every send decision, so `trust --add`/`--remove` apply\n   immediately, including to a `serve` process already running. For a\n   grant you don't want to keep, there is a session-scoped form:\n   `whatsapp-connect-mcp trust --session --add <jid>` elevates a recipient\n   for the life of the current `serve` process only — never written to\n   `config.json`, wiped automatically the next time `serve` starts.\n   Use it when you are actively drafting a thread with one person or group\n   and have already confirmed the first sends by hand; it cuts the\n   draft-and-confirm round-trip for that recipient without granting\n   anything permanent. Like persistent trust it is CLI-only (no MCP tool\n   can grant it), and block/unblock still draft on every call regardless.\n4. **Rate limit, always.** Every send — drafted, trusted, whatever —\n   consumes a token from one rate limiter shared across all five send\n   tools. The interval has a hard 5-second floor that no configuration can\n   go below. A rate-limited commit leaves the draft valid; retry the same\n   call with the same token once the limit clears.\n\n`mark_read` is the one exception to drafting: a read receipt isn't authored\ncontent, so it always sends on the first call (still rate-limited, still\ngated).\n\n### Which files a send may attach\n\nThe gate above authorises a *recipient*. It says nothing about the *file* a\nsend names, so on its own it would let a manipulated model attach anything\nthis program can read — an SSH key, a password store — to a recipient you\nhad already trusted.\n\nSo outbound files are confined to an allowlist of directories. The default\nis a single dedicated one, created on first run:\n\n| OS | Default outbox |\n|---|---|\n| Linux | `~/.config/whatsapp-connect-mcp/outbox` |\n| macOS | `~/Library/Application Support/whatsapp-connect-mcp/outbox` |\n| Windows | `%AppData%\\whatsapp-connect-mcp\\outbox` |\n\nMove a file there before sending it, or widen the list by setting\n`media_roots` in `config.json` to absolute directory paths:\n\n```json\n{ \"media_roots\": [\"/home/you/Pictures\", \"/home/you/Documents\"] }\n```\n\nPaths are resolved before they are checked, so a symlink inside an allowed\ndirectory is judged by where it actually leads, not where it sits. A send\nnaming a file outside the list is refused on the first call — before a draft\nis minted and before it costs a rate-limit token — and the refusal names no\npath, like every other error this server returns.\n\n## Comparison with verygoodplugins/whatsapp-mcp\n\nThe current best-known alternative works, but is painful to adopt and has\nno send safety:\n\n| | verygoodplugins/whatsapp-mcp | whatsapp-connect-mcp |\n|---|---|---|\n| Runtimes required | Go **and** Python, two processes | One static binary, zero prerequisites |\n| Install | Clone repo, run bridge manually, hand-edit client config, restart | One-line install → `setup` wizard auto-injects clients |\n| Pairing | QR in a terminal you keep open yourself | Wizard-managed QR pairing; session supervised by the binary |\n| Send safety | None — model can send immediately | Draft-first send gate + rate limiter |\n| Prompt-injection defense | None | Untrusted-data banner on every WhatsApp-originated result |\n| Diagnostics | None | `doctor` (CLI subcommand and MCP tool), sanitized output |\n| Distribution | Git clone only | GitHub Releases, install script, MCP Registry, MCPB bundle, npm wrapper |\n\n## Ban risk\n\nMeta detects third-party clients in two independent ways, and only one of\nthem is behavior.\n\n**1. The client is identifiable.** A linked device announces itself when it\nregisters. whatsmeow's defaults announce an OS string of `whatsmeow` with an\nunknown platform type, which is distinguishable from an official client by\nreading the pairing payload alone. This project overrides that and announces\na Chrome browser identity instead (`internal/bridge/clientinfo.go`), which is\nalso what your phone shows for this device under Linked Devices.\n\nDo not mistake that override for a fix. It defeats the most trivial version\nof the check and not the underlying problem. `serve` and `setup` do refresh\nthe reported WhatsApp Web version before connecting, so the version and the\nbuild hash derived from it track a real release rather than whichever one\nwas vendored at build time — but the user agent still carries whatsmeow's\nplaceholder carrier and manufacturer fields, and the session behaves on the\nwire like whatsmeow, not like Chrome. Users of\nwhatsapp-web.js — which drives a real Chrome browser with a genuine\nfingerprint — received the same warnings described below, which suggests the\nannounced identity was never the deciding signal. Changing it also does\nnothing for a session that is already paired: the identity is sent when\npairing, so an existing session keeps whatever it registered with until you\npair it again.\n\n**2. Behavior.** Reported triggers, roughly by how often they come up:\nmessaging people who never messaged you first, high send velocity, volume\nsoon after pairing, the same message sent repeatedly, automated Status posts,\nand noisy reconnection loops.\n\nThe uncomfortable part is that the public evidence points at (1) as the\ndominant factor. In [whatsmeow#810](https://github.com/tulir/whatsmeow/issues/810)\n— the May 2025 \"your account may be at risk\" wave, closed `not planned` in\nJuly 2026 — users report the warning on accounts that were idle and merely\nconnected, having never sent a message, and on accounts that had been\ndisconnected for weeks. Users of whatsapp-web.js, an entirely different\nimplementation, received it too. A Baileys maintainer in that same thread\nargues the opposite, that it is \"mostly a behavioral issue.\" Nobody\nestablished which, and the thread was closed without an answer.\n\nSo: the send gate and rate limiter here are real mitigations for (2) and do\nnothing for (1). On the available evidence, behaving well affects when your\nturn comes rather than whether it comes.\n\nReports worth reading before you pair, dated so you can judge how current\nthey are:\n\n| Report | Opened | Last activity |\n|---|---|---|\n| [whatsmeow#810](https://github.com/tulir/whatsmeow/issues/810) — \"account may be at risk\" wave | May 2025 | Jul 2026 (closed) |\n| [Baileys#2309](https://github.com/WhiskeySockets/Baileys/issues/2309) — permanent ban after automated Status posts | Jan 2026 | May 2026 (open) |\n| [Baileys#1869](https://github.com/WhiskeySockets/Baileys/issues/1869) — five suspensions in a week, on instances running 3+ years | Oct 2025 | May 2026 |\n\nTreat ban statistics from vendor blogs — \"68% of businesses banned within 12\nmonths\", \"a rolling 30-day no-reply threshold\" — as unsourced marketing from\npaid Business API resellers. No primary source supports them, and neither\nnumber appears in this document for that reason.\n\n## Limitations (stated plainly)\n\n- **Your number can be banned, and this project cannot prevent it.** See\n  [Ban risk](#ban-risk). This is the limitation that matters most.\n- **History depth is phone-decided.** Like every WhatsApp Web client, the\n  paired phone controls how much chat history syncs to this server. There\n  is no setting here that fetches more than the phone hands over.\n  `setup --full-history` asks for as much as the protocol allows instead of\n  the default few months, but it is a request, not a setting — and it only\n  applies when pairing. For an install that is already paired, the\n  `fetch_older_messages` tool asks the phone for more of a single chat\n  without re-pairing. Both are requests the phone is free to answer with\n  less, or nothing; neither recovers messages the phone itself has deleted.\n- **Voice notes need Ogg Opus input.** `send_voice_note` does no\n  transcoding. If your source audio isn't already `.ogg`/Opus, convert it\n  first (e.g. `ffmpeg -i in.mp3 -c:a libopus out.ogg`).\n- **No outbound calls.** Call history is readable; initiating a call is not\n  supported.\n- **One paired number per install.** Multi-account isn't supported in v1.\n- **whatsmeow tracks WhatsApp protocol changes**, not the other way around.\n  A WhatsApp-side change can break pairing or sending until whatsmeow (and\n  in turn this project) catches up.\n\n## Data and privacy\n\nEverything — session keys, messages, media, contacts, call log — lives in a\nlocal SQLite database under this program's data directory. Nothing about\nyour messages, contacts, or media is sent anywhere by this server.\n\nExactly two outbound network calls exist beyond the WhatsApp connection\nitself. Both are best-effort, both time out after 2 seconds, and neither\ncarries message content, a JID, a phone number, or any session credential:\n\n- `doctor`/`check` asks GitHub's public release API whether a newer version\n  of this program exists. It never blocks or fails the check when GitHub is\n  unreachable.\n- `serve` and `setup` fetch the current WhatsApp Web client version from\n  `web.whatsapp.com` before connecting, so the version this client reports\n  tracks a real release instead of whichever one was vendored at build time.\n  A failure is reported and ignored; a stale version still connects.\n\nThe data directory:\n\n| OS | Path |\n|---|---|\n| Linux | `~/.config/whatsapp-connect-mcp` |\n| macOS | `~/Library/Application Support/whatsapp-connect-mcp` |\n| Windows | `%AppData%\\whatsapp-connect-mcp` |\n\n## Diagnostics\n\n```sh\nwhatsapp-connect-mcp check\n```\n\nRuns the same checks the `doctor` MCP tool exposes: session pairing/connect\nstate, event-flow liveness (a connected session that has received no\nWhatsApp events for over 30 minutes gets a warning — the state where the\nsocket looks healthy but ingestion has silently stalled), message database\nintegrity, injected MCP client configs, data\ndirectory permissions (POSIX), and the version check above. Every finding\nis sanitized — no JID, phone number, message content, or filesystem path\never appears in a status line; a broken client config is named by the\nclient's name, never its path on disk.\n\n## Dashboard\n\n```sh\nwhatsapp-connect-mcp dashboard [--port n]\n```\n\nPrints (and tries to open) a one-time login link for a small web dashboard\nserved alongside `serve --http` — it shows connection health, store row\ncounts, and the same doctor findings `check` prints, refreshed every few\nseconds. The link exchanges the HTTP transport's existing bearer token for\na session cookie, so nothing new needs to be configured or trusted.\n\nThe dashboard only ever listens on loopback, exactly like the HTTP\ntransport it shares a port with: `serve --http` must already be running,\nand the page is unreachable from any other machine. Log back in with the\n`dashboard` command any time the session expires (a server restart, most\noften) — the printed token is never written to a server log.\n\nWhen the session is unpaired, the dashboard's Pair tab shows the QR code\nright in the browser — start pairing there and scan it with WhatsApp >\nLinked devices > Link a device, no terminal needed. This also covers\nre-pairing after a WhatsApp-side logout. When the session is paired, the\nsame tab offers Unlink: it signs the server out on WhatsApp's servers\n(the phone stops listing it under Linked devices) and brings the QR back.\nThe `logout` command does the same from the terminal — unlike `remove`,\nwhich only deletes the local session and never tells WhatsApp.\n\nThe Trust tab lists and edits the trusted-contact list — the same\nconfig.json the `trust` command manages, so a change there takes effect\nimmediately in a running server. The Schedules tab lists pending scheduled\nsends and lets you cancel one. The Drafts tab lists sends an agent has\nproposed and is waiting on; approving delivers the exact content shown\n(rate-limited as always), and discarding drops it. A draft can be\ncommitted at most once no matter whether the dashboard or the agent's own\nretry gets there first. The Backup tab writes a snapshot with one click,\nexactly like the `backup` command below.\n\n## Backing up\n\n```sh\nwhatsapp-connect-mcp backup [--dest path]\n```\n\nWrites a consistent snapshot of the message database (`messages.db`) to\n`<data-dir>/backups/messages-<timestamp>.db` (or a custom path via `--dest`).\nThe backup is a standalone, fully-usable SQLite database — not a copy of\nsessions or settings, just messages. Unlike a phone backup, a `backup`\nsnapshot is safe to take while `serve` is running; SQLite's WAL mode and\nbusy timeout guarantee consistency.\n\nMessage history is the one thing that cannot be recovered any other way — a\nsession can be re-paired if needed, but messages fetched from the phone stay\non the phone only as long as the phone remembers them, which is typically\na few months. A regular automated backup (via `cron`, a systemd timer, or the\nTask Scheduler on Windows) is the simplest insurance against losing them.\n\n## Other commands\n\n```sh\nwhatsapp-connect-mcp setup [--full-history]  # pair (again) and configure MCP clients\nwhatsapp-connect-mcp status                  # pairing state, row counts, injected clients\nwhatsapp-connect-mcp clients [--remove]      # list or uninject MCP client entries\nwhatsapp-connect-mcp trust [--session] [--add jid|--remove jid|--list]\nwhatsapp-connect-mcp serve [--http addr]     # run the MCP server directly (stdio by default)\nwhatsapp-connect-mcp service <install|uninstall|restart> [--http addr]\n                                             # manage a background serve --http service (macOS/Linux/Windows)\n```\n\n> **`--http` requires a bearer token and a loopback Host.** On first use it\n> generates a 256-bit token, writes it to `.http-token` in the data\n> directory (owner-only), and prints it once — put it in your client's\n> `Authorization: Bearer <token>` header. Every request must also be\n> addressed to a loopback Host (`localhost`, `127.0.0.1`, `[::1]`), which\n> blocks a web page in your browser from reaching the server by rebinding\n> DNS to a loopback address. Still bind `127.0.0.1`: the token guards\n> against reaching the port, but binding a public interface exposes it to\n> your whole network, and if you must, put your own access control (a\n> reverse proxy, a VPN, a firewall rule) in front.\n\n## Updating\n\nUpdating replaces the binary and nothing else: pairing, message history,\nthe trust list, and injected client configs all live in the data directory\nand survive every update. Use the same method you installed with — each\nputs the new binary at the same path the old one occupied, so client\nconfigs keep working:\n\n```sh\n# macOS / Linux — the install script always fetches the latest release\ncurl -fsSL https://raw.githubusercontent.com/idle-sync/whatsapp-connect-mcp/main/scripts/install.sh | sh\n```\n\n```powershell\n# Windows (PowerShell)\nirm https://raw.githubusercontent.com/idle-sync/whatsapp-connect-mcp/main/scripts/install.ps1 | iex\n```\n\n```sh\n# npm global install\nnpm update -g whatsapp-connect-mcp\n\n# npx without an install — @latest bypasses npx's cached copy\nnpx whatsapp-connect-mcp@latest setup\n```\n\nThen restart what runs the binary: stdio clients pick the new version up\nwhen the MCP client next starts a session (restart the client app). With\nthe http transport, restart `serve` — for a service installed with\n`service install`, that is:\n\n```sh\nwhatsapp-connect-mcp service restart\n```\n\nA kept-alive service never re-execs on its own, so until it is restarted\nthe old version keeps serving.\n\nYou don't have to watch the releases page — `whatsapp-connect-mcp check`\nand the `doctor` MCP tool compare the running version against the latest\nrelease on every run, and warn with both versions named when they differ.\n\n## Uninstall / reset\n\n- **`whatsapp-connect-mcp remove`** deletes the local WhatsApp session\n  (unpairs this server from it locally — the next `setup` requires pairing\n  again). This is local-only: it does not notify WhatsApp's servers, so\n  your phone keeps showing this device as linked under Linked Devices until\n  you unlink it there yourself. Prompts for a typed `yes` before doing\n  anything.\n- **`whatsapp-connect-mcp reset`** does everything `remove` does, plus\n  deletes stored messages, media, and settings — a full wipe back to a\n  fresh install. Also prompts for a typed `yes`.\n- **`whatsapp-connect-mcp clients --remove`** uninjects this program's\n  entry from any MCP client config it was added to, without touching the\n  paired session.\n- To remove the binary itself, delete it from wherever the installer put\n  it (`~/.local/bin`, `%LOCALAPPDATA%\\Programs\\whatsapp-connect-mcp`, or\n  wherever `npx` cached it) and delete the data directory listed above.\n\n## License\n\nMIT — see [LICENSE](LICENSE).\n",
  "bytes": 27944,
  "sha": "d5e36b2cf234213c4766d0f04cc160a76c697be48227829afd3e2195ebde6053",
  "repo_slug": "idle-sync/whatsapp-connect-mcp",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_idle_sync_whatsapp_connect_mcp_f9c75249/readme"
}