wazap-mcp

Remember something about a person

remember

Idempotent

Store private local notes, tags, and contact details about people from WhatsApp chats without writing them to WhatsApp; mark requests handled or exclude contacts from catch-up.

Instructions

Keep what the user says about someone, locally, never on WhatsApp: a note, tags, details find_contact matches ({"relatie": "mama"}), or handled: true for an ask dealt with elsewhere. #private keeps their words out of what you did not ask about them by name; #no-catchup keeps them out of catch_up.

Input Schema

Name	Required	Description
`note`	No	"" removes it
`fields`	No	e.g. {"nickname": "Mișu", "role": "contabil"}; "" deletes a key
`chat_id`	Yes	Several: tags and fields only
`handled`	No	Off catch_up's waiting until they write again
`add_tags`	No	e.g. ["client"]
`account_id`	No
`remove_tags`	No
`remove_fields`	No

Output Schema

Name	Required	Description
`name`	No
`note`	No
`tags`	No
`fields`	No
`number`	No
`people`	No	Several chat_ids: each one's card
`chat_id`	No
`handled`	No	The ask taken off the waiting list; null when nothing was open
`account_id`	Yes
`is_business`	No
`is_my_contact`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv1.6.0Oct 22, 2026

removedInput schema / properties / account_id / description
```
Removed value: -"Account id"
```

addedInput schema / properties / chat_id / anyOf

Added value: +[
+  {
+    "description": "Chat id, or a phone number",
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "items": {
+      "$ref": "#/properties/chat_id/anyOf/0"
+    },
+    "maxItems": 50,
+    "minItems": 1,
+    "type": "array"
+  }
+]

changedInput schema / properties / chat_id / description

Previous value: -"Chat id, or a phone number"New value: +"Several: tags and fields only"

removedInput schema / properties / chat_id / minLength
```
Removed value: -1
```
removedInput schema / properties / chat_id / type
```
Removed value: -"string"
```

addedOutput schema / properties / people

Added value: +{
+  "description": "Several chat_ids: each one's card",
+  "items": {
+    "additionalProperties": true,
+    "properties": {},
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "chat_id",
-  "name",
-  "account_id"
-]New value: +[
+  "account_id"
+]

Addedv1.0.3Sep 23, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare non-read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower, and the description still adds genuinely new context: storage is local and never written to WhatsApp, and the privacy flags alter how the record is exposed in later reads. The explanation of #private ('keeps their words out of what you did not ask about them by name') is confusing enough to blunt the value, but the disclosure is substantive.

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?

The core constraint (local, never on WhatsApp) is front-loaded, and there is little outright filler. But the single run-on sentence stacks four distinct payload types and two hashtag modifiers into one breath, making it harder to parse than it needs to be.

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

Completeness3/5

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

An output schema exists, so return values need no explanation, and the annotations cover the safety profile. Still, for an 8-parameter mutation tool with nested objects, the description leaves gaps: precedence when note/fields/add_tags/remove_tags are combined, behavior on a chat_id array (only 'tags and fields only' is hinted), and the relationship to the 'learn' sibling.

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

Parameters3/5

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

Schema coverage is 63%, so the schema carries most of the burden, and the description does add meaning for 'fields' by tying it to what find_contact matches, plus the deletion semantics for note. It says nothing about account_id, remove_tags, remove_fields, or the array form of chat_id beyond the schema's own note, so it only partially compensates for the coverage gap.

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 ('Keep what the user says about someone, locally') and enumerates what can be stored: note, tags, matched details, and the handled flag. It also implicitly distinguishes itself from send_message by saying 'never on WhatsApp'. The phrasing is compressed and jargon-heavy, but an agent can identify the operation.

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?

It gives conditional guidance for two cases ('handled: true for an ask dealt with elsewhere', '#no-catchup keeps them out of catch_up'), which is real when-to-use signal. However, it never explains how this differs from the sibling tool 'learn', nor does it state prerequisites such as a linked account or what happens on conflicting writes. Usage is implied rather than fully specified.

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