Skip to main content
Glama

Send a free-form WhatsApp text message

send_whatsapp_message
Destructive

Send a free-form WhatsApp text message

Free-form text is restricted to Meta's 24-hour customer-service window (the customer must have messaged the agent within the last 24 hours). Outside the window, use POST /v1/whatsapp/templates instead.

The agent is the body's agent_id, judged as on every agent endpoint: an API key needs it on its agent list; an AI assistant needs full access, and the person it acts for must have that agent as a member, admin or owner. An agent_id that is missing or not a UUID is 422 invalid_agent_id.

The MCP server sends this call with an idempotency key of its own, so a retry after a timeout never sends it twice.

Input Schema

NameRequiredDescriptionDefault
toYesE.164 international phone number — leading `+`, country code, then 7–15 digits. No spaces, dashes, or parens.
fromYesE.164 international phone number — leading `+`, country code, then 7–15 digits. No spaces, dashes, or parens.
textNo
agent_idYesID of the Mojeeb agent to send from.
media_urlNoOne file to send: an https link Mojeeb downloads (a public address, no redirects) or the `url` of a Mojeeb upload of the agent (`createUpload`). A JPEG, PNG or WebP image up to 10 MB, an MP4 or MOV video up to 16 MB (re-encoded for WhatsApp; videos sent with messages have a budget of their own, 10 a minute per key, past which they are `429 video_send_rate_limited`), or a PDF or DOCX document up to 20 MB.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / media_url
      Added value: +{
      +  "description": "One file to send: an https link Mojeeb downloads (a public address, no redirects) or the `url` of a Mojeeb upload of the agent (`createUpload`). A JPEG, PNG or WebP image up to 10 MB, an MP4 or MOV video up to 16 MB (re-encoded for WhatsApp; videos sent with messages have a budget of their own, 10 a minute per key, past which they are `429 video_send_rate_limited`), or a PDF or DOCX document up to 20 MB.",
      +  "maxLength": 4096,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "agent_id",
      -  "from",
      -  "to",
      -  "text"
      -]New value: +[
      +  "agent_id",
      +  "from",
      +  "to"
      +]
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

With annotations already covering safety and openness, the description adds real value: the full agent authorization model (API key agent list vs. AI assistant `full` access plus membership role) and the concrete `422 invalid_agent_id` failure mode. It also discloses that the MCP server injects its own idempotency key so retries after timeouts do not double-send; this sits in mild tension with `idempotentHint: false` but describes server-side retry handling rather than contradicting the underlying call's semantics.

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 critical constraint (24-hour window) and the alternative are front-loaded in the first two sentences, with auth and idempotency detail after. The authorization paragraph is dense but every clause is actionable for an agent that needs to diagnose a permission failure.

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 a 5-parameter mutating tool with a nested object and no output schema, the description covers eligibility, alternative routing, authorization, an error code, and retry behavior. It stops short of saying what a successful send returns or how to confirm delivery, though `get_whatsapp_message_status` exists as a sibling for that.

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 already 80%, so the baseline is 3; the description earns an extra point by explaining what `agent_id` means as an authorization subject rather than just an identifier, including how it is validated. `from`/`to`/`text` semantics are left entirely to the schema, which documents them well.

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?

The opening line states a specific verb and resource and immediately qualifies it with 'free-form', which is the discriminating characteristic versus template messaging. It points to the template path as the alternative, though it cites the raw API route `POST /v1/whatsapp/templates` rather than the sibling tool `send_whatsapp_template`, adding a small lookup step for the agent.

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?

It gives an explicit eligibility condition — the customer must have messaged within the last 24 hours — and an explicit when-not with a named alternative for outside that window. No inference is required to decide between this tool and template sending.

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