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
• 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>

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, 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.

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

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.