Skip to main content
Glama

send_whatsapp_message

Send a WhatsApp text or template message from a connected business number. Pick the sender with connection_id OR number_id (exactly one). Returns Meta's wamid; delivery is asynchronous — subscribe to the whatsapp.event.received webhook, which relays Meta's status payloads verbatim. Sautikit stores no messages, so there is no conversation history to read back: the wamid is your correlation handle. IMPORTANT: free-form text is only permitted inside the 24-hour customer service window the contact opened by messaging you; outside it, send type "template" with a Meta-approved template or the send is rejected.

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": {
      "to": "<to>",
      "type": "<type>"
    },
    "name": "send_whatsapp_message"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesrecipient WhatsApp id (a phone number, e.g. 254700000001)
textNorequired when type is text: {body, preview_url}
typeYes"text" for a free-form message (only allowed inside the 24-hour customer service window the contact opened by messaging you) or "template" for a Meta-approved template (allowed any time)
purposeNoRequired on tools that read data or reports; recommended on every tool. One sentence: what you are doing and why (for example "finding this caller's open ticket to answer them"). Building a report, dashboard, analytics or an export is a SautiDesk Pro feature done by the report tools, not by pulling records.
templateNorequired when type is template: {name, language_code, components}; the template must already be approved by Meta
number_idNoSautikit number id (a UUID from list_numbers) to send from — NOT Meta's phone_number_id; Sautikit maps it to Meta's id by matching the number E.164 against connected WhatsApp accounts. Mutually exclusive with connection_id
connection_idNoUUID of the WhatsApp connection to send from; mutually exclusive with number_id

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations, which only declare destructiveHint=false and openWorldHint=false. It discloses the return value (Meta's wamid), that delivery is asynchronous and observable only via the whatsapp.event.received webhook, that no messages are stored so there is no history to read back, and the concrete failure mode (rejection outside the 24-hour window). That is exactly the operational context an agent needs to avoid a false 'delivered' assumption.

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 action, then sender selection, then return/webhook semantics, then the binding 24-hour restriction flagged as IMPORTANT. Dense but purposeful; only minor overlap exists between the description's template rule and the schema's type description.

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

Completeness5/5

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

For a 7-parameter mutation tool with nested objects and no output schema, the description supplies everything material: what is returned (wamid), how outcome is observed asynchronously, and the compliance rule that determines whether a call will be rejected. Nothing an agent needs in order to call it correctly is absent.

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 the schema already documents to, text, template, number_id, connection_id and purpose. The description reinforces the sender XOR rule and the text-vs-template gating, but adds little that is not already present in the property descriptions; the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource (send a WhatsApp text or template message) plus the scope constraint (from a connected business number). It immediately distinguishes the two message modes and the sender-selection mechanism, so an agent knows this is the outbound send tool, not the typing-indicator, read-receipt, or call-permission siblings.

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?

Strong conditional guidance: choose exactly one of connection_id or number_id, and use type "text" only inside the 24-hour customer service window, otherwise type "template" with a Meta-approved template. What is missing is explicit routing against siblings such as desk_send_dm or desk_send_sms, so the agent must infer that this tool is the WhatsApp-specific channel.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources