Skip to main content
Glama

neuron

by io.github.conquext
OverviewDiscussionsAdmin

Send WhatsApp Message

neuron_send_whatsapp

Send a WhatsApp message to a phone number or group. Auto-resolves which channel to use (org default > first connected). Supports text, image, audio, video, and document types.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesRecipient: phone number (e.g., '2348012345678') or group JID (e.g., '120363XXX@g.us')
textNoMessage text content (optional when sending a template)
sendAtNoISO 8601 date-time for scheduled delivery (e.g., '2025-12-31T10:00:00Z'). Message sends immediately if omitted.
mediaUrlNoURL of media to attach (required for non-text message types)
templateNoApproved template (official WhatsApp Business API sessions only). Required to reach anyone who hasn't messaged you in the last 24 hours. Set messageType to 'template'.
channelIdNoUnique identifier (UUID) of a specific channel to override auto-resolution
contactNameNoDisplay name for the recipient contact
messageTypeNoMessage type: 'text' (default), 'image', 'audio', 'video', 'document', or 'template' (official API sessions)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / messageType / description
      Previous value: -"Message type: 'text' (default), 'image', 'audio', 'video', or 'document'"New value: +"Message type: 'text' (default), 'image', 'audio', 'video', 'document', or 'template' (official API sessions)"
    • addedInput schema / properties / template
      Added value: +{
+  "additionalProperties": false,
+  "description": "Approved template (official WhatsApp Business API sessions only). Required to reach anyone who hasn't messaged you in the last 24 hours. Set messageType to 'template'.",
+  "properties": {
+    "components": {
+      "description": "Meta send-time components with variable values, e.g. [{ type: 'body', parameters: [{ type: 'text', text: 'Ada' }] }]. Omit for templates without variables.",
+      "items": {
+        "additionalProperties": {},
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "language": {
+      "description": "Template language code, e.g. 'en_US'",
+      "type": "string"
+    },
+    "name": {
+      "description": "Template name exactly as approved (see neuron_list_whatsapp_templates)",
+      "type": "string"
+    }
+  },
+  "required": [
+    "name",
+    "language"
+  ],
+  "type": "object"
+}
    • changedInput schema / properties / text / description
      Previous value: -"Message text content"New value: +"Message text content (optional when sending a template)"
    • changedInput schema / required
      Previous value: -[
-  "to",
-  "text"
-]New value: +[
+  "to"
+]
  2. Changed1 schema field changed
    • addedInput schema / properties / sendAt
      Added value: +{
+  "description": "ISO 8601 date-time for scheduled delivery (e.g., '2025-12-31T10:00:00Z'). Message sends immediately if omitted.",
+  "type": "string"
+}
  3. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds genuinely useful behavior beyond them: the channel-selection precedence order and the set of supported media types. It stops short of mentioning the 24-hour session window or delivery/rate behavior, though the 24-hour rule is covered in the template schema field.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the core action and channel-resolution behavior front-loaded ahead of the type enumeration. Every clause earns its place.

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?

For an 8-parameter, nested-object tool with no output schema, the description plus a fully-covered schema give the agent enough to invoke it correctly. The remaining gap is routing context — nothing tells the agent how this differs from the other send_* siblings.

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 nested template object and sendAt scheduling) is already documented in the schema. The description's 'supports text, image, audio, video, and document' echoes messageType semantics without adding format or constraint detail, so the baseline 3 applies.

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?

Specific verb+resource ('Send a WhatsApp message') plus explicit recipient scope (phone number or group) and supported message types. It does not, however, differentiate itself from the numerous sibling senders such as neuron_send_message, neuron_bot_api_send, or neuron_send_broadcast, leaving the agent to guess which endpoint is the WhatsApp-specific one.

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?

The channel auto-resolution note ('org default > first connected') gives useful implied context, but the description never states when to choose this tool over the alternative send tools, nor any exclusions or prerequisites. Usage must be inferred from the name.

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

All neuron toolsInspect
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.

Resources