Whatsapp MCP Stream

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>

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.