WhatsApp Business API by Wassenger

manage_whatsapp_message_interactions

Manage WhatsApp message interactions including replies, forwards, reactions, and poll voting. Handle all message interaction operations with action-based approach for comprehensive message engagement functionality.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>",
      "chat": "<chat>"
    },
    "name": "manage_whatsapp_message_interactions"
  }
}

Input Schema

Name	Required	Description
`chat`	Yes	WhatsApp chat ID (e.g., 1234567890@c.us for phone numbers, 123456789000000000@g.us for groups, 123456789000000@newsletter for WhatsApp channels)
`vote`	No	Vote details (required for vote action)
`agent`	No	Agent ID (24 character hex string)
`quote`	No	Message ID to reply to (required for reply action)
`action`	Yes	Action to perform for WhatsApp message interactions
`device`	No	Target WhatsApp device ID (24 character hex string) used for message delivery. Only required if you have multiple WhatsApp numbers connected. Use MCP tool "get_whatsapp_devices" to retrieve a list of available devices.
`forward`	No	Forward message details (required for forward action)
`message`	No	Reply message content (required for reply action)
`reaction`	No	Emoji reaction to send, use "-" to remove reaction (required for reaction action)
`selectId`	No	ID of selected button/list option when replying to interactive messages (for reply action)
`reference`	No	Custom reference ID for message tracking
`idempotencyKey`	No	Your unique key for this message, 6 to 36 characters (a UUID works). Reuse the same key when retrying the same message: the API then answers 409 Conflict with the id of the message already created instead of sending it twice. Use a new key for every different message.
`reactionMessage`	No	Message ID to react to (required for reaction action)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

addedInput schema / properties / idempotencyKey

Added value: +{
+  "description": "Your unique key for this message, 6 to 36 characters (a UUID works). Reuse the same key when retrying the same message: the API then answers 409 Conflict with the id of the message already created instead of sending it twice. Use a new key for every different message.",
+  "maxLength": 36,
+  "minLength": 6,
+  "type": "string"
+}

First observedOct 26, 2026

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden, and it discloses almost nothing behavioral: no permission requirements, no note that reaction action can remove a reaction via '-', no explanation that each action requires different companion parameters, no failure or retry semantics. The only behavioral detail in the whole tool (idempotency/409 behavior) lives in the schema, not the description.

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 first sentence is efficient and front-loaded with the useful enumeration. The second sentence is largely redundant restatement ('Handle all message interaction operations... comprehensive message engagement functionality') that adds no information and pads the definition.

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

Completeness2/5

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

A 13-parameter mutation tool with nested objects, no annotations, and no output schema needs the description to explain action-conditional requirements and effects, which it does not. An agent must reverse-engineer the dispatch logic entirely from the schema, leaving real gaps for a multi-action tool.

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 description coverage is 100%, so every parameter including the action-conditional nested objects (vote, forward) is documented in the schema; the baseline of 3 applies. The description adds no clarification of the critical action-to-parameter mapping, but the schema already carries that weight.

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 ('manage') and resource ('WhatsApp message interactions') and enumerates the four operations that match the action enum exactly: replies, forwards, reactions, poll voting. It is clear what the tool does, though it never contrasts itself with the close sibling send_whatsapp_message, so an agent must infer the reply-vs-send boundary.

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

Usage Guidelines2/5

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

There is no when-to-use guidance beyond the vague phrase 'action-based approach for comprehensive message engagement functionality.' Nothing tells the agent which action to pick for a given user intent, what prerequisites each action has, or when to use send_whatsapp_message instead of action=reply.

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

All WhatsApp Business API by Wassenger tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.