WhatsApp Business API by Wassenger

send_whatsapp_message

Comprehensive WhatsApp message sending with action-based operations. Supports all message types including text, media, location, contact, poll, event messages, with scheduling, live delivery, expiration, agent messaging, and template support. All message sending operations unified in one tool.

Scheduling: pass exactly one of deliverAt, delay or delayTo on the text, media, template, agent or scheduled actions. Leaving all three out sends the message right away. On WhatsApp Cloud API (WABA) numbers a plain text, media or agent message still needs the customer to have written within the last 24 hours at delivery time, so a reminder that lands later than that must use the template action.

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": "send_whatsapp_message"
  }
}

Input Schema

Name	Required	Description	Default
`chat`	Yes	WhatsApp chat ID (e.g., 1234567890@c.us for phone numbers, 123456789000000000@g.us for groups, 123456789000000@newsletter for WhatsApp channels)
`poll`	No	Poll content (required for poll action)
`agent`	No	Agent ID (24 character hex string)
`delay`	No	Deliver the message after this many seconds (max 31536000, a year)
`event`	No	Event content (required for event action)
`media`	No	Media content (required for media action)
`order`	No	Ensure strict message delivery order
`action`	Yes	Action to perform for WhatsApp message sending
`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.
`actions`	No	Actions to perform after message delivery (for agent action)
`agentId`	No	Agent ID for agent messaging (required for agent action)
`delayTo`	No	Deliver the message after a duration: 30m, 2h, 3d, 2w, 1M (max a year)
`enqueue`	No	Message delivery mode (for live action)	never
`message`	No	Text message content (required for text, scheduled, live, expiring, agent, template actions)
`contacts`	No	Array of contacts to send, max 10 (required for contact action)
`location`	No	Location content (required for location action)
`template`	No	Template configuration (required for template action)
`deliverAt`	No	Absolute ISO 8601 instant to deliver the message at, with a time zone (e.g. 2026-09-20T09:00:00+02:00). Must be in the future and less than a year away
`reference`	No	Custom reference ID for message tracking
`expiration`	No	Time-to-live duration e.g. "1h", "30m", "2d" (for expiring action)
`previewUrl`	No	Enable URL preview in messages (for text, template actions)
`sendReadAck`	No	Send chat read acknowledgment after the message is delivered
`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.

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

A3.6/5.0

Behavior3/5

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

With no annotations, the description does meaningful work: it discloses the 24-hour messaging window constraint, the template workaround for late deliveries, and the scheduling exclusivity rule. It still omits other behavioral facts an agent needs for an irreversible outbound side effect — required permissions/plan, rate limits, whether a sent message can be recalled, and what the call returns (no output schema exists).

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?

Purpose is front-loaded and the scheduling rules are well consolidated, but the opening is padded: 'Comprehensive ... with action-based operations', the long type enumeration that restates the `action` enum, and 'All message sending operations unified in one tool' all repeat the same idea. The high-value second paragraph is buried under that redundancy.

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 23-parameter nested tool with zero annotations, the description covers the riskiest dimension (timing and the 24-hour window) well. It is incomplete on the return path — with no output schema and no mention of what comes back (message ID, reference, delivery status), an agent cannot plan retrieval or retry without falling back to `idempotencyKey` guessing.

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 100%, so 3 is the baseline, but the description adds real semantics beyond the schema: mutual exclusivity among the three scheduling parameters and the send-immediately default. That is guidance the schema's per-property descriptions do not express. It says nothing about `order`, `enqueue`, `sendReadAck`, or `reference` beyond what the schema already states.

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 concrete verb+resource ('send WhatsApp message') and enumerates the message types the single `action`-driven tool handles, so the agent knows this is the general send entry point. It also claims all sending is 'unified in one tool,' which implicitly separates it from post-send mutation tooling, but it never names the nearest alternative (`send_whatsapp_flow`, `manage_whatsapp_message_interactions`, `manage_whatsapp_channel_messages`).

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 scheduling paragraph is genuinely instructive: exactly one of `deliverAt`, `delay`, or `delayTo`, omitting all three sends immediately, and it names the condition (delivery outside the 24-hour customer-service window on WABA numbers) that forces the `template` action instead. What's absent is guidance on choosing this tool over `send_whatsapp_flow` or the interaction-management tools.

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.