Skip to main content
Glama
hermoso-ai

Hermoso

Official

Broadcast a WhatsApp template to many people

send_whatsapp_broadcast

Send an approved WhatsApp template to many recipients in a paced, queued broadcast; validate with dry-run, confirm, and track per-recipient outcomes via job ID.

Instructions

Send ONE approved WhatsApp template to MANY recipients — a customer list, a segment, a launch announcement. TEMPLATES ONLY: WhatsApp accepts free-form text only inside the 24-hour customer-service window that opens when THAT person messages the business, so a free-form broadcast is a separate bet on a separate window per person and Meta refuses each closed one. META HAS NO BULK ENDPOINT, so this is a paced fan-out — one message per recipient, about 10 a second — which is why it runs as a QUEUED JOB and returns a job id rather than a result: nothing has been sent when the call returns. Poll it by calling this tool again with jobId (or use get_job), and read the PER-RECIPIENT outcome; a partial failure is reported as one, never as success. PER-RECIPIENT VARIABLES ARE THE POINT: pass recipients as objects { to, components } so each person gets their own {{1}}, {{2}} values in a single broadcast. Duplicates are removed (the same number twice is a second charge for one person and trips Meta’s 6-second per-recipient limit) and unusable numbers are REFUSED BY NAME rather than silently dropped — pass skipInvalid:true to send to the rest, and they are still named in the result. RUN IT WITH dryRun:true FIRST: that costs nothing, sends nothing, and reports the exact recipient count, the template’s real category, what Meta bills for it, and whether the list fits inside the business portfolio’s moving 24-hour messaging limit. ⚠ META DOES NOT DELIVER MARKETING MESSAGES TO WHATSAPP USERS IN THE UNITED STATES AT ALL (error 131049, platform-wide since 1 April 2025) — the sends are still ACCEPTED and given message ids, so a US marketing broadcast looks like a success and is not one; the dry run says how many recipients are on +1. META BILLS THE BUSINESS, not Hermoso credits: per message delivered, at Meta’s own per-country rates, marketing always charged and utility/authentication free inside an open service window. WhatsApp policy REQUIRES the recipient’s opt-in first and nothing in the API enforces it — Meta punishes it afterwards through quality rating. Confirm-gated in code: show the user the message, the template and the recipient count, get an explicit yes, then call again with confirm:true AND confirmCount set to the exact number of distinct recipients. ACCEPTED IS NOT DELIVERED — never report a broadcast as delivered. 0 Hermoso credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobIdNoREAD MODE — pass a broadcast’s job id (and nothing else) to get its status and per-recipient outcome instead of starting a new one
dryRunNocost nothing, send nothing, queue nothing: report exactly who would be messaged, what Meta charges for it, and whether it fits the 24-hour messaging limit
wabaIdNothe account the template is read from. Optional — it defaults to the account that owns phoneNumberId, and one naming a DIFFERENT account is refused
confirmNoREQUIRED true — this sends real messages to real phones and Meta bills the business for every one
languageNowhich language of that template, e.g. en_US. Omitted, Hermoso uses the first one it finds and reports which.
templateNoan APPROVED template name. Required to SEND — a broadcast cannot be free-form text; omit only when reading a broadcast back with jobId
componentsNotemplate values SHARED by every recipient, in Meta’s component form. A per-recipient `components` overrides it. The count must match the template’s {{1}}, {{2}} placeholders — Hermoso checks that against the real template and refuses a provable mismatch before anything is dispatched
recipientsNothe list: either phone numbers in full international form ["+14165550142", …], or objects { to, components } when each person gets different template values. Duplicates are removed and counted; invalid numbers are refused by name unless skipInvalid is true
skipInvalidNodrop unusable numbers instead of refusing the whole list. They are still named in the result — nothing is ever silently dropped
confirmCountNoREQUIRED — the exact number of DISTINCT valid recipients, echoed back. confirm:true alone cannot tell a 12-person test from a 2,000-person send
phoneNumberIdNoWHICH NUMBER IT SENDS FROM — from list_whatsapp_accounts (a WABA can have several). Required to SEND; omit only when reading a broadcast back with jobId
Behavior5/5

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

The description goes far beyond the annotations. It discloses the queued-job behavior, the lack of a bulk endpoint (paced fan-out), the partial-failure reporting, duplicate removal, refusal of invalid numbers, the US non-delivery issue with error 131049, billing model, opt-in requirements, and the confirm-gating flow. These are all critical behavioral details that annotations (readOnlyHint:false, openWorldHint:true) do not capture. No contradiction exists.

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?

The description is long but densely packed with essential information, and critical warnings are emphasized with caps and exclamation marks. It front-loads the primary purpose and then systematically covers constraints, billing, policy, and operational flow. While every sentence adds value, the sheer length may be overwhelming, and some redundancy (e.g., 'ACCEPTED IS NOT DELIVERED' repeated twice) could be trimmed. Still, the structure is logical and scannable.

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 tool with 11 parameters and no output schema, the description covers the entire workflow: how to run a dry run, how to confirm, what happens with duplicates, invalid numbers, per-recipient variables, billing, US restrictions, and how to read results via jobId. It even explains the partial-failure reporting and the 24-hour messaging limit. Nothing an agent needs to operate the tool correctly is left unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant meaning to several parameters: it clarifies that `recipients` can be phone numbers or objects with per-recipient components, explains `skipInvalid` behavior ('refused by name unless skipInvalid is true'), describes `confirmCount` as echoing the distinct-recipient count, and emphasizes `dryRun` as a cost-free pre-flight. It also explains the interplay between `jobId` read-mode and sending mode, and why `template` must be approved. This enriches every parameter's semantics.

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 description opens with a precise, specific statement — 'Send ONE approved WhatsApp template to MANY recipients' — naming the verb, the resource, and the scope. It draws a clear line against free-form text and single-recipient uses, and the contrast with send_whatsapp_message is implicit but evident from the 'many recipients' framing. The purpose is unmistakable.

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 description gives strong context on when to use this tool — when broadcasting a template to many people, with a note that free-form text is only allowed in the 24-hour service window. It also advises running `dryRun:true` first and explains the confirm-gating flow. However, it does not explicitly name the alternative tool (send_whatsapp_message) for single sends, leaving that comparison to be inferred. Otherwise, usage boundaries are well defined.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hermoso-ai/hermoso'

If you have feedback or need assistance with the MCP directory API, please join our Discord server