Skip to main content
Glama
razvangirgiz

wazap-mcp

by razvangirgiz

Semantically search WhatsApp history

recall
Read-onlyIdempotent

Search whole WhatsApp history by meaning and exact words at once. Ask in your own words or another language, and get the message you're looking for, even if you forget the exact phrasing.

Instructions

Search by meaning and by words at once over the whole WhatsApp history — answers "the invoice Dan mentioned", "the address Ana sent", "what did they say about the trip". A paraphrase or another language still hits through its meaning, and a short or foreign-language question still hits through its words; the two rankings are fused. A match found by meaning weighs a little less with age (85% a month on, never under 70%), so the fresher of two close matches comes first but a clearly closer old one still does; one chat takes at most three leading places before other chats' hits, and a near-duplicate trails the list. For an exact string — an id, a phone number, a URL — search_messages is the better tool.

Each result carries its date, a fused score, matched ("words", "meaning" or "both") and the cosine similarity when its meaning ranked it. chat_id, since, until and from narrow the search exactly like search_messages — including a name that resolves to exactly one person. A hit marked "index only" is a message wazap holds only as text: quote its words; get_message returns them, but download_media has nothing to open and it cannot be replied to or forwarded. A hit found only by meaning must clear the similarity floor, so a question with no answer comes back empty; when only weak meaning matches survive, the output says so — do not present them as found facts.

When semantic recall is off or its embedding setup is missing, the tool does not dead-end: it falls back to a keyword search over the local history, marked mode: "keyword_fallback", and recall_unavailable.fix names the command that turns semantic recall on. An error remains only when even the fallback cannot run.

Each hit's sender carries the same identity fields as search_messages, and freshness says whether the local history may be partial or stale. Every answer also declares its window: the semantic path reports how many messages the index covers, and a keyword fallback carries the same coverage block search_messages does.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fromNoOnly messages this person sent: "me", a phone number, a contact/chat id, or a name that resolves to exactly one person (the error names the candidates when it does not)
limitNoMaximum number of results (1-50)
queryYesWhat to find, said any way — the meaning is what matches
sinceNoOnly messages from this moment on: a date ("2026-09-01") or an ISO timestamp
untilNoOnly messages up to this moment: a date or an ISO timestamp
chat_idNoRestrict the search to this chat
account_idNoRegistry account id (default, work, …). Omit to resolve from chat_id or message_id, or the default account.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.21.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations (readOnly/openWorld/idempotent/non-destructive), the description discloses many behavioral traits: fused ranking, age weighting (85% a month, never under 70%), per-chat placement caps, near-duplicate handling, similarity floor, keyword fallback with mode marker, index-only limitations, and coverage/freshness reporting. This is far more than the annotations alone convey.

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

Conciseness5/5

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

The description is long, but every paragraph earns its place given the tool's complex fusion and fallback behavior. It is front-loaded with the core purpose, then proceeds logically through output fields, parameter semantics, edge cases, and failure modes. There is no filler or tautology.

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?

For a sophisticated search tool with no output schema, the description covers return values, ranking semantics, filtering behavior, index-only limitations, fallback mode, error conditions, and coverage/freshness fields. Combined with 100% schema coverage and strong annotations, nothing essential is missing for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: query is 'said any way — the meaning is what matches', from supports name resolution to exactly one person, and since/until narrow exactly like search_messages. It does not redundantly re-explain every field, yet enriches the params with behavioral detail.

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

Purpose5/5

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

The description opens with a specific, vivid statement of what the tool does: 'Search by meaning and by words at once over the whole WhatsApp history'. It gives concrete example queries and explicitly contrasts itself with search_messages for exact strings, so an agent can distinguish it from siblings without inspecting schemas.

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?

It explicitly names when to prefer search_messages ('For an exact string — an id, a phone number, a URL') and when this tool is the right choice (meaning-based or word-plus-meaning search). It also explains fallback behavior when semantic recall is unavailable, and says quote words for 'index only' hits with get_message as the recovery path.

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