wazap-mcp

Catch up on what the user missed

catch_up

Read-only

Retrieve what you missed across WhatsApp accounts, including waiting asks, mentions, calls, people, groups, and stories, within a token budget and with cursor pagination.

Instructions

What the user missed, all accounts, within budget_tokens: waiting (every open ask of 14 days, whatever the window), mentions, calls, people, groups, stories. account_id narrows it to one account; get_status names them. The mark moves first; a lost answer is since: "previous". more.cursor: the rest.

Input Schema

Name	Required	Description
`hours`	No	The last N hours instead; never moves the mark
`since`	No	"last" (default); "previous" repeats that catch-up; or an ISO date or time from the last 14 days
`cursor`	No	more.cursor
`include`	No	Only these sections; the mark then stays
`account_id`	No
`budget_tokens`	No	Answer length in tokens

Output Schema

Name	Required	Description
`more`	Yes	Set when entries are left: call catch_up again with more.cursor
`notes`	No	Caveats to act on or tell the user
`direct`	Yes
`footer`	Yes	On the last page: what the entries leave out
`groups`	Yes
`window`	Yes
`stories`	Yes
`waiting`	Yes
`accounts`	Yes
`addressed`	Yes
`account_id`	Yes
`missed_calls`	Yes
`approx_tokens`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.6.0Oct 22, 2026
- removedInput schema / properties / account_id / description
```
Removed value: -"Account id"
```
- addedOutput schema / properties / direct / items / properties / tags
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```
- addedOutput schema / properties / waiting / items / properties / tags
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```
Addedv1.0.3Sep 23, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true and idempotentHint=false, and the description explains the non-obvious reason: 'The mark moves first', so a repeat call is not idempotent and a swallowed answer requires since: "previous". That is real side-effect disclosure the annotations cannot convey.

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

Conciseness3/5

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

Every clause carries information and the scope comes first, but the telegraphic fragments ('The mark moves first', 'more.cursor: the rest', 'a lost answer is since: "previous"') force the reader to reconstruct the grammar, which costs clarity for very little length saved.

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

Completeness4/5

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

With an output schema present, return values need not be explained, and the description covers the remaining gaps: breadth across accounts, the token budget, the mark/cursor/repeat interaction. Only the 'waiting' 14-day exception ('whatever the window') is stated so tersely that its interaction with 'hours' stays murky.

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 already 83%, so the baseline is 3, and the description still adds meaning: 'hours ... never moves the mark', 'include' makes the mark stay, 'more.cursor: the rest', 'since: "previous" repeats that catch-up'. These are behaviors of the parameters, not restatements of their types.

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?

The description opens with 'What the user missed, all accounts' and enumerates the sections returned (waiting, mentions, calls, people, groups, stories), so the resource and scope are clear. It never names a verb, but the digest nature distinguishes it well enough from search/read_messages siblings.

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

Usage Guidelines3/5

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

'account_id narrows it to one account; get_status names them' gives a concrete routing rule to a sibling. However there is no statement of when to prefer this over read_messages or search, and the 'lost answer is since: "previous"' hint is recovery guidance rather than use-case guidance.

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