Skip to main content
Glama

WA MCP

send_message

Sends a WhatsApp message to one person or group: text, or a file (photo, document/PDF, voice note, audio file or sticker) with optional text as its caption. On the free plan, text works only to people who have messaged the user in the last 90 days (starting new conversations needs the paid plan), and "Sent via wa-mcp.com" is added at the end of it; files (media) need the paid plan. to can be a contact name, a phone number with country code, or a JID (…@s.whatsapp.net, …@lid, …@g.us); if a name could match more than one contact, call search_contacts first. To reply to a specific message (a quoted reply), pass its id from read_chat_history or search_messages as quote_id. To send a file, pass media with exactly one source: media.url, a link to the file; media.message_id, the id of a photo, video, voice note, audio, document or sticker message from read_chat_history or search_messages, to send that file on to someone (e.g. "send Ana the photo Juan sent me"); or media.data, base64 for small files you generated yourself (up to 512 KB). You can't pass on a file the user attached to this conversation: ask them to upload it to Google Drive, click Share, set access to "Anyone with the link", and paste the link here; pass that link unchanged as media.url. Google Drive file links, and Google Docs (sent as PDF), Sheets (XLSX) and Slides (PDF) links work directly; so does any public direct link to a file. Don't upload the user's files to other sites without asking them. The type is detected from the file: JPEG/PNG/WebP/GIF go as photos, MP4 (H.264) as a video, OGG/Opus audio as a voice note, other audio (MP3, M4A) as an audio file, everything else (PDF, Office files, other videos such as iPhone MOV/HEVC, HEIC) as a document. A file sent on with media.message_id keeps its kind (a voice note stays a voice note, a document keeps its name) and isn't marked as forwarded; its original caption isn't copied, so pass text for one. Limits: photos, videos and audio 16 MB, documents 32 MB. If you are writing the text yourself rather than sending words the user gave you, call get_writing_style for this chat first and write it the way the user writes; skip that for dictated text. To protect the user's number from WhatsApp's anti-spam bans, messages that start a conversation with someone who hasn't messaged the user in the last 90 days may be limited to 1 per minute and 10 every 12 hours; the result says so and explains why when it happens. People who have written to the user are never limited. Sending can't be undone: confirm the recipient, text and file with the user first unless they already gave them. Returns { to, status (sent, failed, or scheduled), recipient, message_id, media?, text_message_id?, note?, error?, scheduled_id?, send_at? }: recipient is who the message went to, with the contact fields (name; name_source: address_book, push_name, group_subject, business, phone or unresolved; canonical_jid: the JID to pass to send_message and read_chat_history; phone_jid and lid_jid: the chat's phone-number and LID forms, null when unknown or for groups; phone_display: the number as +). scheduled means the new-contact limit moved the message to the next free minute: it goes out by itself at send_at (scheduled message scheduled_id), so don't send it again. message_id can be used as quote_id later. With media, media says how the file was sent ({ sent_as, mimetype, size_bytes, file_name? }) and note explains a fallback (e.g. a HEVC video sent as a document); tell the user. If WhatsApp rejects the send, the result is an error that still includes recipient and error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesContact name, phone number with country code, chat JID (person or group), or a group's exact name (case, accents, spaces and punctuation ignored; part of a group name doesn't match).
textNoThe message text. With media, the caption of a photo or document (for audio and stickers, it is sent as a separate message just before the file). Required unless media is given.
mediaNoOptional. A file to send. Pass exactly one of url, message_id or data.
quote_idNoOptional. The `id` of the message to reply to (from read_chat_history or search_messages).
quote_participantNoOptional. The quoted message's `sender_jid` (from read_chat_history). Usually looked up automatically from quote_id; pass it if a group reply asks for it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior3/5

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

Extremely rich beyond the annotations: free-plan 90-day window, the 'Sent via wa-mcp.com' footer, media requiring a paid plan, anti-spam throttling of 1/min and 10/12h for new contacts, size limits, and that sends cannot be undone. However, 'Sending can't be undone' sits awkwardly against destructiveHint=false — not a genuine contradiction (no data is destroyed), but the description never reconciles the irreversibility with the declared safety profile, and the wall of plan/limit detail dilutes the core behavioral signal.

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

Conciseness2/5

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

A single ~600-word paragraph that buries the return-value contract, the type-detection table, and the anti-spam limits inside the same block. Purpose is front-loaded, but the density and duplication with the schema make it hard to scan, and several clauses (Google Drive share instructions, HEIC/MOV examples) could be compressed.

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 a destructive-free but irreversible write tool with a nested `media` object and no output schema, the description covers everything an agent needs: recipient resolution, plan gating, rate limits, quoting, file sourcing constraints, and even the full return shape (status sent/failed/scheduled, recipient fields, error handling).

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%, so the baseline is 3, but the description still adds real meaning: it explains the mutually exclusive sources of `media` (url vs message_id vs data with the 512 KB cap), the file-type detection table, what `to` accepts, and that `media.message_id` preserves the file's kind without copying its caption. It mostly restates schema content, which caps it below a 5.

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?

Opens with a specific verb+resource ('Sends a WhatsApp message to one person or group') and immediately enumerates the payload kinds (text, photo, document/PDF, voice note, audio, sticker). It is unambiguously distinguishable from siblings like schedule_message, edit_message, or react_to_message.

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?

Gives concrete routing rules: call search_contacts first when a name is ambiguous, call get_writing_style before composing text yourself (and skip it for dictated text), use quote_id from read_chat_history/search_messages for replies, and confirm with the user before sending. Each alternative tool is named with the condition that selects it.

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