Skip to main content
Glama
razvangirgiz

wazap-mcp

by razvangirgiz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Wait for new WhatsApp messages

wait_for_messages
Read-onlyIdempotent

Wait for incoming WhatsApp messages up to a timeout and return them with a cursor, so agents can process new messages without gaps; filter to direct messages, mentions, and replies.

Instructions

Wait for messages from other people, up to timeout_seconds, and return them with a cursor: pass it to the next call so nothing that lands between calls is missed. addressed_to_me wakes only for direct messages, mentions and replies to the user. For agents that stay on the line.

Input Schema

NameRequiredDescriptionDefault
cursorNoFrom the previous call
chat_idNoChat id, or a phone number
account_idNo
addressed_to_meNo
timeout_secondsNo

Output Schema

NameRequiredDescriptionDefault
countYes
cursorYesPass to the next call
messagesYes
timed_outYes
account_idYes
cursor_resetYesThe cursor was from another run; the wait started now

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.6.0
    • removedInput schema / properties / account_id / description
      Removed value: -"Account id"
  2. Changed6 schema fields changedv1.0.3
    • changedInput schema / properties / account_id / description
      Previous value: -"Registry account id (default, work, …). Omit to resolve from chat_id or message_id, or the default account."New value: +"Account id"
    • removedInput schema / properties / addressed_to_me / description
      Removed value: -"Only direct messages, @-mentions of the user and replies to the user's messages"
    • changedInput schema / properties / chat_id / description
      Previous value: -"Only messages in this chat"New value: +"Chat id, or a phone number"
    • changedInput schema / properties / cursor / description
      Previous value: -"The cursor returned by the previous call"New value: +"From the previous call"
    • removedInput schema / properties / timeout_seconds / description
      Removed value: -"How long to wait (1-55 s)"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "account_id": {
+      "type": "string"
+    },
+    "count": {
+      "type": "number"
+    },
+    "cursor": {
+      "description": "Pass to the next call",
+      "type": "string"
+    },
+    "cursor_reset": {
+      "description": "The cursor was from another run; the wait started now",
+      "type": "boolean"
+    },
+    "messages": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "chat_id": {
+            "type": "string"
+          },
+          "message_id": {
+            "type": "string"
+          },
+          "private": {
+            "const": true,
+            "description": "Tagged #private: no words",
+            "type": "boolean"
+          },
+          "text": {
+            "type": "string"
+          },
+          "timestamp": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "message_id",
+          "chat_id",
+          "text",
+          "timestamp"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "timed_out": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "count",
+    "messages",
+    "cursor",
+    "timed_out",
+    "cursor_reset",
+    "account_id"
+  ],
+  "type": "object"
+}
  3. Addedv0.15.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover readOnly, idempotent, open-world and non-destructive, so the safety profile is done. The description adds genuinely non-obvious behavior: the call blocks for up to timeout_seconds, returns a cursor whose reuse prevents gaps between calls, and addressed_to_me narrows wake-ups to DMs, mentions and replies. It omits what is returned when the timeout elapses with no messages, which is the main behavioral gap.

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?

Front-loaded with the core action and its timing constraint, then the cursor contract, then the filter. Three dense clauses with no repetition of annotations. 'For agents that stay on the line' is a slightly decorative closer, but it frames the intended usage rather than wasting space.

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?

Return values are covered by the existing output schema, and the crucial cross-call cursor contract is spelled out, which is what an agent needs to loop correctly. Missing only the empty-timeout outcome and any guidance on chat_id/account_id scoping; for a 5-param, zero-required tool that is close to complete.

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 only 40%, so the description must compensate, and it does for three of five params: cursor provenance, addressed_to_me's exact semantics, and timeout_seconds as an upper bound. chat_id and account_id are left to the schema (chat_id has a description there, account_id has none), which is a minor shortfall rather than a blocker.

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 ('wait for messages'), plus scoping ('from other people, up to timeout_seconds') and a distinguishing long-poll mechanism (cursor returned and passed back). It does not name the close siblings read_messages or catch_up, so an agent must infer the difference, but the 'wait/block' semantics separate it from the fetch tools.

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?

'For agents that stay on the line' and 'pass it to the next call so nothing... is missed' imply the streaming/long-poll use case, but there is no explicit when-to-use-vs-alternatives guidance — nothing says to prefer read_messages for a one-shot fetch or catch_up for backlog. Usage is inferable rather than stated.

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

Deploy Server

Other Tools