WhatsApp MCP Stream

A WhatsApp MCP server built around Streamable HTTP transport, using Baileys for WhatsApp connectivity, with a web admin UI and bidirectional media flow (upload + download).

Key points:

• Transport: Streamable HTTP at /mcp

• Engine: Baileys

• Admin UI: QR, status, logout, runtime settings, chat history viewer

• Media: upload endpoints + /media hosting + MCP download tool

Quick Start (Docker)

# build and run

docker compose build

docker compose up -d

The server will be available at:

• Admin UI: http://localhost:3003/admin

• MCP endpoint: http://localhost:3003/mcp

• Media files: http://localhost:3003/media/<filename>

Related MCP server: whatsapp-mcp

DNS on hosts with --iptables=false

On some NAS / hardened hosts (e.g. Synology with dockerd --iptables=false), Docker's embedded DNS proxy (127.0.0.11) has no iptables DNAT rules and refuses connections inside containers.

Fix: copy resolv.conf.example to resolv.conf and add a volume override:

cp resolv.conf.example resolv.conf

Then add to a local docker-compose.override.yml (not committed):

services:
  mcp-whatsapp:
    volumes:
      - ./resolv.conf:/etc/resolv.conf:ro

docker compose up picks up the override automatically.

Runtime Settings

Settings can be edited in the admin UI and are persisted to SETTINGS_PATH (defaults to MEDIA_DIR/settings.json).

Admin UI

Admin console with runtime settings, QR linking, chat history viewer, export, and status.

Supported settings:

• media_public_base_url

• upload_max_mb

• upload_enabled

• max_files_per_upload

• require_upload_token

• upload_token

• auto_download_media

• auto_download_max_mb

Authentication

Built-in authentication is not implemented yet. In production, use a gateway that enforces auth. This project works well behind authmcp-gateway:

https://github.com/loglux/authmcp-gateway

Media Upload API

Base64 JSON:

curl -X POST http://localhost:3003/api/upload \
  -H "Content-Type: application/json" \
  -d {filename:photo.jpg,mime_type:image/jpeg,data:<base64>}

Multipart (recommended for large files):

curl -X POST http://localhost:3003/api/upload-multipart \
  -F "file=@/path/to/file.jpg"

Both return url and (if configured) publicUrl.

Sending Local Files via send_media

The ./files/ directory in the project root is bind-mounted into the container at /app/files. Drop any file there and reference it immediately — no container restart needed:

# On host:
cp report.pdf /path/to/whatsapp-mcp-stream/files/

# In send_media:
media_path: /app/files/report.pdf

For a URL source, pass media_url directly to send_media or stage_media — the server downloads the file itself without base64.

Upload Auth (Optional)

If require_upload_token=true, provide a token with either:

• x-upload-token: <token>

• Authorization: Bearer <token>

MCP Transport

The server exposes Streamable HTTP at /mcp.

Typical flow:

1. POST /mcp with JSON-RPC initialize

2. Use the returned mcp-session-id header for subsequent requests

3. POST /mcp for tool calls

Note: clients must send Accept: application/json, text/event-stream on initialize.

Smoke Test

Quick regression smoke for MCP tools:

npm run smoke:mcp

Optional custom target:

MCP_BASE_URL=http://localhost:3003 npm run smoke:mcp

MCP Tools

Auth

Contacts

Chats

Messages

Media

Utility

Recovery Notes

This service contains an intentional recovery workaround for Baileys/WhatsApp session-state corruption.

Why it exists:

• In production we observed cases where the container stayed alive and MCP still answered, but the WhatsApp session was functionally broken.

• The most common indicators were Baileys errors like failed to find key ... to decode mutation and failed to sync state from version.

• In that state, a manual container restart often restored service.

Current behavior:

• On app-state corruption signals, the service first tries a soft recovery with forceResync().

• If the same class of failure repeats within a time window, it escalates to an internal WhatsApp client restart.

• On disconnects such as Connection Terminated, the service schedules a disconnect watchdog and escalates to an internal restart if the socket does not return to open in time.

• The reconnect lifecycle is guarded against nested lock deadlocks, so disconnect recovery can complete without requiring a manual container restart.

• Recent production observations show repeated socket disconnects (428 Connection Terminated, 503 Stream Errored) being auto-recovered back to open.

• A dedicated /healthz endpoint reports 503 only when the service is genuinely stuck outside the allowed recovery window.

• Docker health checks use /healthz, so the container is restarted only after in-process recovery has had a chance to work.

These recovery mechanisms reduce operator intervention and improve resilience against common WhatsApp/Baileys session failures.

License

MIT

Persistence

Chats and messages are persisted to a local SQLite database stored in the session volume.

Environment variables:

Additional transport diagnostics:

• /mcp POST requests now log request lifecycle events in logs/mcp-whatsapp.log

• this includes request entry, transport dispatch, transport.handleRequest completion, and HTTP finish / close

• use these logs to determine whether latency happens before the response leaves whatsapp-mcp-stream or after that on the gateway/client side

Chat History API

Browse stored chats and messages via:

GET /api/chats?limit=50&offset=0&q=<search> — paginated chat list, optionally filtered by name.

GET /api/chats/:jid/messages?limit=50&offset=0 — paginated messages for a chat (newest first).

Both endpoints are used by the Chats tab in the admin UI.

Export

Export a chat (JSON + optional downloaded media) via:

GET /api/export/chat/:jid?include_media=true

If include_media=true, the ZIP includes files already downloaded via download_media. It does not fetch missing media from WhatsApp.