WhatsApp Read Agent

Strictly read-only access to your own WhatsApp history and attachments, for an AI assistant (via the Model Context Protocol) or any script that reads the local archive.

It is built so that reading and writing are physically separated:

The MCP server has no code path to send, reply, react, call, archive, delete, mark-read, pay, or transfer — those tools are not registered and the WhatsApp socket is not even imported into that process. src/server.test.ts asserts the tool surface is exactly the seven read-only tools, so a mutating tool cannot be added without a test failing.

⚠️ Read this before linking a device

• This is unofficial. It links a companion device using the multi-device protocol (via @whiskeysockets/baileys), the same mechanism as WhatsApp Web, but programmatically. This is not an official WhatsApp API and may violate WhatsApp's Terms of Service. Automating a client can get the account banned. There is no sanctioned API that exposes personal 1:1/group history — the official WhatsApp Cloud API only handles messages to a registered business number. Use this only on your own account, understanding that risk.

• Everything derived from a linked account stays local and gitignored: companion-device credentials (auth/), the message archive (data/), and downloaded media (media/). Never commit them. The device credentials grant full account access — treat them like a password.

• Attachment downloads are double-gated: an explicit per-message approval flag and an optional operator allowlist of chat JIDs. The MCP server only ever surfaces bytes the collector already downloaded; it never reaches out to WhatsApp to fetch anything.

Related MCP server: WhatsApp MCP Server

Install & test

cd whatsapp-agent
npm install            # MCP SDK + zod (Baileys is an optional dep, see below)
npm run check          # build + 31 unit/integration tests (no device or network needed)

The pure read model, deterministic pagination, consent gate, and path-safety checks are all covered by tests that run offline. The collector's WhatsApp handling requires a live device and cannot be exercised in CI.

Link a device and sync (collector)

The collector needs the optional dependency:

npm install @whiskeysockets/baileys qrcode-terminal
cp .env.example .env    # adjust paths / limits if desired
npm run collect         # prints a QR (or a pairing code if WHATSAPP_PAIR_NUMBER is set)

On your phone: WhatsApp → Settings → Linked devices → Link a device, then scan the QR (or choose "Link with phone number" and enter the printed pairing code). The collector then receives the history sync and writes it to data/ (and attachments to media/). Keep it running to keep the archive current. Re-run it anytime to resume.

Wire up the MCP server

Build first (npm run build), then point your MCP host at the built entry:

{
  "mcpServers": {
    "whatsapp-read": {
      "command": "node",
      "args": ["/absolute/path/to/rs-website-firebase/whatsapp-agent/dist/index.js"],
      "env": {
        "WHATSAPP_DATA_DIR": "/absolute/path/to/whatsapp-agent/data",
        "WHATSAPP_MEDIA_DIR": "/absolute/path/to/whatsapp-agent/media",
        "WHATSAPP_ATTACHMENT_ALLOWLIST": ""
      }
    }
  }
}

The server loads the archive at startup. After a fresh sync, restart it to pick up new messages.

Tools (all read-only)

Cursors are opaque — pass them back verbatim.

Verification / readback test

The task's acceptance test ("prove complete readback against Anuj Kapoor and Rajesh Aggarwal") requires a linked device and therefore must be run on a machine with the phone available:

1. npm run collect and link the device; wait for get_sync_status to report a non-zero messageCount and stable lastSyncAt.

2. Start the MCP server (or use the archive directly).

3. find_chats_by_name → "Anuj Kapoor", then "Rajesh Aggarwal" to get each chat JID.

4. get_history with direction: "forward", paging on nextCursor until hasMore is false — that is the complete, ordered history with exact isoTime timestamps.

5. For any attachment, list_attachments then get_attachment with approved: true.

The deterministic pagination and the end-to-end "locate named chat → page complete history" flow are proven in src/read-api.test.ts and src/server.test.ts against seeded Anuj/Rajesh fixtures. The live readback against the real account was not run here: this environment is headless (no phone to scan the QR, no persistent host), so a device cannot be linked from it. Run steps 1–5 on your own machine to complete the acceptance test.