Skip to main content
Glama

extract_whatsapp

Extracts and segments the conversations of a WhatsApp export (.zip or .txt containing chat.txt in UTF-8 with at least one turn) and, unless it is a preview, resolves each selected conversation with AI by transcribing voice/audio/video notes and describing visual expressions, returning the segmented conversations with speakers, dialogs, counts and usage. Provide the export as file_base64 (base64 of the .zip/.txt bytes) plus optional filename. Use dry_run=true for a PREVIEW: it validates the file, segments the conversations, counts media and ESTIMATES the credits WITHOUT calling the AI and WITHOUT charging (credits_charged=0), returning object whatsapp_preview with credits_total, the params actually used, the windows, per-conversation items and warnings. The window is given either as a single start/end pair or as windows, a JSON string holding a non-empty list of sub-objects each with start and end; windows must not be combined with start/end, and a windows selection is the deduplicated chronological union of the overlaps, which bypasses the noise filter and keeps conversations that are monologues or below min_messages, while for a single window sending only one of start/end is rejected and empty/all-zeros values select the real period of the export, both being allowed to be omitted in dry_run while outside dry_run both absent is rejected. timezone and date_format are required, where date_format must be day_first, month_first or year_first. gap_minutes is optional (default 720) and splits conversations on idle gaps, min_messages is optional (default 2) and is the minimum messages kept per conversation outside the explicit windows selection, voice_note is optional (default true) and turns voice/audio/video media into text, expression is optional (default true) and describes visual expressions (figurinha, GIF, emoji), and client_reference_id is optional, echoed verbatim, charset A-Za-z0-9 space _/:.- up to 60 chars. Outside the preview, this call consumes credits and the amount actually charged is returned in usage.credits_consumed; the preview credits_total is an estimate and the preview charges nothing; via MCP the export must stay under about 45 MB (larger exports must go to POST /v1/whatsapp/extractConversations as multipart, limit 1 GB) and the endpoint is stateless (export and media processed in memory, temporary files removed, nothing persisted), returning object conversations with id (wc-), usage and the conversations (conversation_id, first_at, last_at, duration_seconds, speakers, dialog, message_count, characters) plus meta. IMPORTANT: this call charges credits and the result is NOT stored — you MUST read the FULL response and relay ALL of its information to the user (the complete list of conversations with their dialogs and counts, usage and meta; no omissions, no shortening), and persist it if the user may need it later; calling again charges again.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "file_base64": "<file_base64>",
      "timezone": "<timezone>",
      "date_format": "<date_format>"
    },
    "name": "extract_whatsapp"
  }
}

Input Schema

NameRequiredDescriptionDefault
endNo
startNo
dry_runNo
windowsNo
filenameNoexport.zip
timezoneYes
expressionNo
voice_noteNo
date_formatYes
file_base64Yes
gap_minutesNo
min_messagesNo
client_reference_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden and does so: credits are charged, the exact charged amount is in usage.credits_consumed, preview costs nothing (credits_charged=0), the endpoint is stateless with in-memory processing and temp files removed, and the result is NOT stored. It even warns that calling again charges again and instructs the agent to relay the full response.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose, preview mode, window rules, parameters, limits and output are all front-loaded in a logical order with almost no filler. The downside is a dense run-on delivery with no visual breaks, which makes the conditional logic harder to scan than it needs to be for a definition this long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description describes both return objects in detail: whatsapp_preview with credits_total, params used, windows, per-conversation items and warnings; and conversations with id (wc-), usage, per-conversation fields (conversation_id, first_at, last_at, duration_seconds, speakers, dialog, message_count, characters) plus meta. Nothing needed to invoke or interpret the call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage across 13 parameters, the description compensates almost completely: file_base64/filename encoding, timezone and date_format required with the three allowed values, windows as a JSON string of start/end sub-objects with union/dedup semantics, gap_minutes (720), min_messages (2), voice_note (true), expression (true), and client_reference_id charset/length. Start/end edge cases (empty, all-zeros, omitted-in-dry_run) are also covered.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: extracts and segments conversations from a WhatsApp export (.zip or .txt), with AI transcription of voice/audio/video and description of visual expressions in the non-preview path. The two modes (dry_run preview vs. charged extraction) are clearly delineated. It doesn't distinguish itself from the sibling transcribe_audio, which is the one plausible point of confusion for a media-transcribing tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing: dry_run=true for validation/estimate without AI or charge; outside preview it consumes credits. Names the alternative path for oversized exports (>45 MB must go to POST /v1/whatsapp/extractConversations as multipart, limit 1 GB). Also spells out window-selection rules and which parameter combinations are rejected.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources