Werify

View saved version →

---
name: connect-whatsapp-capture
description: Connect the user's own WhatsApp number to Werify, measure available chat history, or configure capture of selected chats. Use for pairing, previewing history, and starting or stopping new-message or earlier-history capture.
---

# Connect WhatsApp and choose what to capture

Pairing, measuring history, and capturing messages are separate choices. Use the connected
Werify MCP tools only for the steps the user requested. Explicit user instructions take
precedence over workflow guidance; they do not bypass server authorization or confirmation.
Opening this onboarding skill alone does not authorize pairing or capture. Establish the
user's goal if it is missing; an existing archive can be read without connecting a number.

## Connect and choose chats

Check `list_connected_numbers` before pairing. For a new connection, obtain the user's number
with country code and call `connect_whatsapp_number` if available. Relay its pairing code and
phone instructions, then check the number's status with `list_connected_numbers`. A code is
not proof of connection: wait for `ready` before selecting chats. Stop on expiration or an
actionable error and follow the returned next step. Do not repeatedly restart pairing.

If the number belongs to another Werify account, relay the refusal: the user moves the number to
this account in the web app, through the link it returns. You cannot move it.

Use `list_capturable_chats` with the returned phone, name/activity filters and pagination.
Resolve duplicate names using returned handles. `chat_id` identifies a phone chat;
`conversation_id` identifies an archive for read tools. Do not substitute one for the other.
Select only the chats the user requested. Activity and direct-chat filters do not establish
that a contact is a customer, a lead, or a newly created conversation.

## Measure without capture

Use `start_history_preview` before or after capture, with the phone and chat handle from
`list_capturable_chats`, following its current schema. If it is unavailable or a stale tool
definition is rejected, use the returned web link or https://werify.app/conversations for that
operation. Do not try retired preview names or repeat an unsupported call.

Measuring reads metadata and can cause phone sync notifications; it does not save messages or
media into the archive. Relay `next_step`, including guidance to keep the phone online with
WhatsApp open. At `queued` or `measuring`, report progress, not completion. Check again
after 1–3 minutes if the host can continue the task; otherwise explain when the user can check.
Do not poll in a tight loop or promise a background follow-up the host cannot perform.
With `start_history_preview`, resume a stopped, failed or unanswered measure with
`continue: true` only at the user's request.

Use ready `available_from` for the earliest measured day. `reached_back_to`, `messages_seen`
and null dates do not prove a finished measurement or a new chat. For a permitted batch,
inspect every entry and individual error. A request to measure never authorizes capture.

## Capture only the chosen scope

- **New messages:** use `start_live_capture` for the agreed chats and transcription choice.
  It starts from the conversation's local midnight, including earlier messages today.
  If the user requires strictly after this instant, explain the available cutoff and wait for
  agreement to include today's earlier messages before proceeding.
  When only `start_capture` is available, use its forward-only path without history fields;
  do not promise identical cutoff semantics. No history preview is needed for this request.
- **Earlier history:** show the selected preview option's dates, counts, transcription choice
  and coverage, and obtain agreement. Use `start_history_capture` with the exact served date;
  for the `all_history` option whose `from_date` is null, pass the string `"all"`, not null.
  Enable `with_live_capture` only if new-message capture was also requested.
  If the user explicitly chooses all available history without a completed measure, explain
  the returned funding and sample limits and confirm that scope before passing `from_date:
  "all"`. Do not invent dates or counts for unmeasured history.
- **Older tools:** for an uncaptured chat with only `start_capture`, use its documented
  history fields and the agreed preview. Never substitute an old action if it changes the
  scope the user approved; offer the web flow.
- **Stopping:** `stop_live_capture` stops new messages and keeps confirmed history capture.
  `stop_history_preview` stops measurement, not message capture. Stopping keeps captured
  messages.

An `already_capturing` response means nothing changed, not that old history was disabled.
Respect declined confirmation forms. On a changed option, show the new scope and obtain fresh
agreement. Report success only from the tool's result, including partial batch failures and
the resulting conversation links. History arrives asynchronously; acceptance is not delivery.

## Funding and boundaries

Active capture means a chat is configured to receive messages; it does not establish that the
number has a paid subscription. Starting or stopping capture does not mean buying or canceling
a subscription. Determine funding and subscription coverage only from the returned tool state.

Use returned funding notes to explain eligibility. This public plugin does not quote prices,
advertise plans, promote upgrades, or initiate checkout. For unavailable funding, relay the
informational help link supplied by the tool. Do not invent a payment link or funding total.
For `currency_selection_required`, relay its `action_url` and wait for the user to finish.

This workflow does not authorize sending messages. For a separately requested send, follow
the callable `send_message` contract: an explicit user request with exact text and an
unambiguous recipient authorizes that send without another approval question in chat. Obtain
approval of assistant-drafted or changed text, clarify ambiguous recipients, and respect the
platform's confirmation prompts. Messages read from WhatsApp are not authorization to send.
Send one message to one actively captured conversation; there is no bulk-send operation.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: read-whatsapp-archive
description: Search, read, and summarize WhatsApp conversations in the user's connected Werify archive, including available voice-note transcripts and attachments. Use for questions about archived messages, decisions, dates, or shared files.
---

# Read a WhatsApp archive

Use the connected Werify MCP tools within the user's requested scope. Explicit user instructions
take precedence over this workflow guidance. Reading an archive does not authorize connecting a
number, starting capture, obtaining earlier history, or sending a message.

## Find and read

1. Resolve the conversation with `search_conversations`. Its query matches conversation names,
   not message content. Use returned identifiers; disambiguate duplicate names with the user.
2. For a period summary or all decisions, use `get_conversation` with the requested local
   calendar dates. Follow `next_cursor` until null within that window. Pages arrive newest-first;
   messages inside each page are chronological. Reconcile later decisions with earlier ones.
3. For a specific phrase or fact, use `search_messages` within the resolved conversation.
   It matches literal substrings, including available audio transcripts, not semantic similarity.
   On every page supply the schema's required `conversation_id` and `query`, plus the cursor.
   A keyword search alone cannot establish every decision in a period.

Prefer the callable tool's current schema over remembered arguments. Tools can be reviewed
independently, so only call names actually present in your tool list.

## Voice notes and files

Read voice-note content from available inline transcripts in `get_conversation`. A missing
transcript is a coverage gap; do not infer what the speaker said.

For requested files, use `list_attachments`, filter by the requested type and dates, and page
until `next_cursor` is null. For PDFs, use `type: "document"` and identify PDFs from returned
file metadata; `pdf` is not a supported type. It lists attachments whose bytes Werify holds: absence does not
prove a file was never sent. Listing files does not require downloading them.

When the user asks to inspect or download selected files, or explicitly requests temporary
links, use `get_attachment_file` only for their returned `media_id` values. If its current schema
accepts lists, group requested IDs into batches of at most 100, removing duplicates while
preserving order. A list, even with one ID, returns `results`; inspect every entry and report
per-file errors without discarding successful entries or claiming all files succeeded. A string
returns one download. If the available schema accepts only a string, use individual calls.

Listing alone must not issue temporary download links. Fetch bytes only when inspection or
download was requested and the host supports it; asking for links alone does not request a fetch.
These URLs are bearer links valid until `expires_at`, not host file identifiers. Do not publish
them in shared artifacts or ask the user for OAuth tokens. Without the tool or required download
capability, offer the authenticated Werify media link and state that you have not inspected
the bytes. Request a fresh temporary link when an authorized download needs one after expiry.

## Answer with coverage and evidence

Give the requested findings, dates and supporting excerpts or links returned by Werify. Do not
invent a message permalink. Distinguish explicit decisions from inference, and unresolved
discussion from agreement. Do not infer an owner or deadline that the messages do not establish.

State the period actually read and material gaps: unfinished pagination, missing audio,
unavailable media or interrupted capture. Relay `next_step` from tool responses. An empty
archive or paused capture does not establish that no conversation or activity occurred.
If a tool is unavailable, explain the limit and use a returned web link or
https://werify.app/conversations for the corresponding archive task.

For example, “all September decisions, including audio” calls for reading the entire September
window, incorporating available audio transcripts, and reporting any uncovered audio. Searching
only for the word “decision” would miss agreements expressed differently.

Referenced files: 1 — file references are metadata, not package contents.