The repository is candid. Read the candor.
A new project called whatsapp-mcp runs a personal WhatsApp reader in one Cloudflare account. Its README says the server links as a device, imports the history WhatsApp provides, stores messages and session credentials in a SQLite-backed Durable Object, and gives connected MCP clients tools to list, read, and search chats. It does not send messages.[1]
That last sentence is useful, but it is not the whole safety case. The tool can return up to 500 messages from one chat and up to 200 search results. Search snippets are clipped, while get_messages returns full stored text. The server can also save names against phone numbers. Those details are visible in the exact source revision inspected for this dispatch.[2]
A missing send button limits one kind of harm. It does not make the archive small.
Separate source, store, client, and model.
The phone remains the account's primary device. The deployed service becomes another holder of message history and live session credentials. An MCP client then requests selected records. The text that client places in model context can reach the company that runs the model, according to the project's own privacy page.[3]
Do not compress those steps into "my agent reads WhatsApp." Write the custody route. Name the account that hosts storage. Name each approved MCP client. Name the model provider used by that client. Record whether requests or responses are retained there.
Unlink and delete are different controls.
The repository says relinking removes the current WhatsApp session but keeps stored messages. Its privacy page gives a separate deletion path: delete the Worker and its Durable Object storage in the Cloudflare dashboard. That is a concrete difference between cutting future access and erasing the copy already made.[3]
Cloudflare's documentation also says a Durable Object can hold persistent storage and can be addressed as a single coordination point. Runtime hibernation resets in-memory state, but persisted storage is a separate concern.[4]
Authentication does not answer every custody question.
The inspected project supports an owner password or a configured login service. It mints bearer tokens for the pairing flow and uses a secure, HTTP-only, same-site browser cookie. That is source-observable behavior, not a security audit or a hosted-deployment test.
The MCP security guide asks servers to bind consent to the requesting client, display requested access, validate redirect URIs, and preserve token audience boundaries. The guide is broader than this project. Use it as a review list for any remote MCP endpoint that fronts sensitive data.[5]
Write the exit drill before the import.
MESSAGE_HISTORY_CUSTODY_PACKET
SOURCE_ACCOUNT=[REQUIRED]
HOSTING_ACCOUNT_OWNER=[REQUIRED]
STORED_DATA=[MESSAGES_SESSION_KEYS_NAMES]
APPROVED_MCP_CLIENTS=[REQUIRED]
MODEL_PROVIDER_PER_CLIENT=[REQUIRED]
MODEL_RETENTION_SETTING=[REQUIRED]
UNLINK_TEST=[REQUIRED]
STORED_COPY_DELETE_PATH=[REQUIRED]
DELETE_VERIFICATION=[REQUIRED]
REVISION_REVIEWED=[REQUIRED]
The custody locker below drafts this review packet. It does not connect to WhatsApp, inspect a deployed Worker, test authentication, or delete data.