Skip to main content
Glama
hermoso-ai

Hermoso

Official

Send a WhatsApp message

send_whatsapp_message

Send a WhatsApp message to a customer using an approved template or free-form reply. Requires confirmation and validates template variables before sending to avoid Meta refusal.

Instructions

Send a WhatsApp message from one of the brand’s registered numbers to a customer. TWO KINDS, and which one is legal depends on time: pass template (an APPROVED template name) to START a conversation — the only thing WhatsApp accepts outside the 24-hour customer-service window — or text for a free-form reply INSIDE that window, which opens only when the customer messages the business first. Hermoso does not receive WhatsApp webhooks yet, so it CANNOT see whether that window is open: a free-form message is sent optimistically and Meta refuses it with a re-engagement error if it is closed, which the reply explains rather than reporting as a broken connection. THIS REACHES A REAL PERSON’S PHONE AND META BILLS THE BUSINESS for the conversation, so it is confirm-gated: show the user the exact message and the recipient, get an explicit yes, then call again with confirm:true. WhatsApp policy REQUIRES the business to hold the recipient’s opt-in first. An unapproved template is refused BEFORE the send, against the status Meta holds. ACCEPTED IS NOT DELIVERED — the reply reports what Meta accepted, and delivery arrives on a webhook we do not receive, so never tell the user it was delivered. THE VARIABLE COUNT IS CHECKED BEFORE ANYTHING IS DISPATCHED: Hermoso reads the template’s own components back from Meta and refuses a payload that supplies the wrong number of values, naming exactly what is missing — for free, before a real phone is involved, instead of Meta answering 132000 after the attempt. It refuses only what it can prove; anything it cannot determine is sent for Meta to judge. 0 Hermoso credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesthe recipient in full international form, e.g. +14165550142
textNoa free-form message — only lands INSIDE the 24-hour window
wabaIdNothe account the template’s review status is read from. Optional — it defaults to the account that owns phoneNumberId, and a wabaId naming a DIFFERENT account is refused rather than silently preferred
confirmNoREQUIRED true — this sends a real message to a real phone and Meta bills the business for it
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 start a conversation outside the 24-hour window
componentsNothe template’s variable values, in Meta’s component form. The count must match the {{1}}, {{2}} placeholders exactly. Hermoso checks this against the template’s real components before dispatching and refuses a provable mismatch by name. A media header needs its own component holding the link even though it carries no {{n}}, and a carousel needs one entry per card.
phoneNumberIdYesWHICH NUMBER IT SENDS FROM — from list_whatsapp_accounts (a WABA can have several)
Behavior5/5

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

The description is exceptionally transparent about side effects and limitations: it cannot see the 24-hour window due to missing webhooks, sends optimistically with possible Meta refusal, bills the business, requires explicit user confirmation, checks variable counts against Meta before dispatch, and clarifies that 'accepted' ≠ 'delivered'. Annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) do not contradict any of this; the description adds substantial context beyond them, including the fact that 0 credits are charged.

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 dense, with every sentence providing actionable information. It is well-structured: starts with the core purpose and the two-mode distinction, then constraints (confirm, opt-in), then internal checks and error semantics. It is not as concise as a short one-liner, but the complexity of the tool merits this length. No fluff or redundancy; front-loads key distinctions.

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?

Given the tool's complexity and the absence of an output schema, the description is remarkably complete. It covers what to do, when to use each mode, side effects, required confirmation, policy prerequisites, error handling, and the meaning of the reply (accepted vs. delivered). Everything an agent needs to invoke this correctly is present, including the 0-credit note.

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% and each parameter has a rich description. The description adds meaningful context: it explains the conditional relationship between template and text, the 24-hour window, and the variable-count check against Meta's components. It also clarifies that components must match placeholders and how media headers/carousels are handled. This goes beyond the schema's static descriptions, justifying a score above the baseline 3.

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 clearly states this sends a WhatsApp message from the brand's registered number to a customer, and immediately distinguishes the two kinds (template vs. text) based on the 24-hour window. It differentiates from the sibling send_whatsapp_broadcast by emphasizing 'a customer' (individual) and 'registered numbers', making the tool's unique role unambiguous.

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

Usage Guidelines5/5

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

Explicitly specifies when to use template vs. text: template for starting a conversation outside the 24-hour window, text only inside the window when the customer initiated contact. It also details the confirm requirement, opt-in policy, and the optimistic-send behavior with a failure mode. This gives an agent precise conditional guidance with clear exclusions and alternatives.

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