Skip to main content
Glama
razvangirgiz

wazap-mcp

by razvangirgiz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Manage a WhatsApp chat

manage_chat
Destructive

Preview and apply WhatsApp chat actions such as archive, pin, mute, clear, delete, block, or mark read, using a confirmation ID for approval.

Instructions

Preview archive, pin, mute, pin_message, star_message, clear, delete, block and undo. After approval repeat chat_id/action with confirmation_id, without options. Expires in 15m; one attempt. mark_read runs directly.

Input Schema

NameRequiredDescriptionDefault
actionYes
chat_idYesChat id, or a phone number
pin_hoursNopin_message: 168 by default
account_idNo
message_idNopin_message, star_message and their undo; in chat_id
mute_hoursNomute: 8 by default
confirmation_idNoFrom preview; omit message/duration options

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.6.0
    • removedInput schema / properties / account_id / description
      Removed value: -"Account id"
    • addedInput schema / properties / confirmation_id
      Added value: +{
+  "description": "From preview; omit message/duration options",
+  "maxLength": 64,
+  "minLength": 1,
+  "type": "string"
+}
  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 / action / description
      Removed value: -"What to do with the chat"
    • changedInput schema / properties / chat_id / description
      Previous value: -"Chat id as returned by another tool (\"<digits>@s.whatsapp.net\" or \"<id>@g.us\"), or a phone number in international format"New value: +"Chat id, or a phone number"
    • changedInput schema / properties / message_id / description
      Previous value: -"The message for pin_message, unpin_message, star_message and unstar_message; it must be in chat_id"New value: +"pin_message, star_message and their undo; in chat_id"
    • changedInput schema / properties / mute_hours / description
      Previous value: -"Hours to mute, default 8; only used by \"mute\""New value: +"mute: 8 by default"
    • changedInput schema / properties / pin_hours / description
      Previous value: -"How long pin_message keeps the message pinned: 24, 168 (default) or 720 hours"New value: +"pin_message: 168 by default"
  3. Changed3 schema fields changedv0.21.0
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "archive",
-  "unarchive",
-  "pin",
-  "unpin",
-  "mute",
-  "unmute",
-  "mark_read",
-  "mark_unread"
-]New value: +[
+  "archive",
+  "unarchive",
+  "pin",
+  "unpin",
+  "mute",
+  "unmute",
+  "mark_read",
+  "mark_unread",
+  "pin_message",
+  "unpin_message",
+  "star_message",
+  "unstar_message",
+  "clear",
+  "delete",
+  "block",
+  "unblock"
+]
    • addedInput schema / properties / message_id
      Added value: +{
+  "description": "The message for pin_message, unpin_message, star_message and unstar_message; it must be in chat_id",
+  "minLength": 5,
+  "type": "string"
+}
    • addedInput schema / properties / pin_hours
      Added value: +{
+  "description": "How long pin_message keeps the message pinned: 24, 168 (default) or 720 hours",
+  "enum": [
+    24,
+    168,
+    720
+  ],
+  "type": "number"
+}
  4. Changed1 schema field changedv0.15.0
    • addedInput schema / properties / account_id
      Added value: +{
+  "description": "Registry account id (default, work, …). Omit to resolve from chat_id or message_id, or the default account.",
+  "minLength": 1,
+  "type": "string"
+}
  5. First observedv0.9.3

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and non-idempotent, and the description adds genuinely new operational facts: a 15-minute expiry, a single attempt per confirmation, and that optional options must be dropped on the confirming call. It does not say what 'clear' versus 'delete' actually removes, which is the one behavioral detail an agent would still want.

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?

Four short sentences with the approval flow and expiry front-loaded and no filler. The telegraphic action list reads as a fragment, but nothing in it is wasted.

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?

For a 16-action, destructive, no-output-schema tool, the description covers the approval mechanics but leaves the action taxonomy under-specified (undo variants and mark_unread unlisted, clear vs. delete undefined) and never states that preview returns a confirmation_id. Adequate to call correctly, but an agent could still mis-select an action.

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?

With 71% schema description coverage, the schema already documents chat_id, message_id, pin_hours, mute_hours and confirmation_id. The description adds the sequencing rule (confirmation call carries only chat_id/action, no options), which is real value, but it never ties message_id to pin_message/star_message or explains which optional parameters pair with which of the 16 enum actions.

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 enumerates the concrete chat operations it fronts (archive, pin, mute, pin_message, star_message, clear, delete, block) and signals a preview-then-confirm shape, so an agent can tell it apart from siblings like manage_group or delete_message. It is slightly incomplete — the un* variants (unarchive, unpin, unblock) and mark_unread are never named, and the mutated resource ('chat') is only implied by the title.

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

Usage Guidelines4/5

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

The two-phase flow is spelled out: first call previews, then 'repeat chat_id/action with confirmation_id', and 'mark_read runs directly' carves out the exception that skips approval. It lacks any guidance on when to prefer this over siblings such as manage_group or delete_message, so the routing context is only partially covered.

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