Skip to main content
Glama

send_poll

Sends a WhatsApp poll (a question with 2 to 12 answer options that people tap to vote) to one person or group, from the user's number. Use it when the user wants to ask a group or a person to choose between options, e.g. "ask the family group which day works for dinner". Paid plan only: on the free plan the call is refused with a note on how to subscribe. to works like send_message's: a contact name, a phone number with country code, a JID, or a group's exact name; if a name could match more than one contact, call search_contacts first. By default each person picks one answer; pass allow_multiple: true to let people pick as many options as they want (e.g. "which days can you come?"). The options must all be different. Votes show up on the user's phone; this server can't read poll results, so don't offer to count the votes. If this number is busy sending other messages, the poll is refused with when to try again. WhatsApp doesn't render Markdown: use bold, italic, strikethrough and "- " lists, and never send tables, # headings, double asterisks or text links. Write a table as short lines (e.g. "Ana: $200") and paste URLs plain. Only format when it suits the message. Messages that start new conversations have extra protection against WhatsApp's anti-spam bans and may be delayed or refused; the result says so and when. Sending the same text, especially with a link, to many people who haven't written to the user can get their number temporarily or permanently banned, even when spaced out: write each person their own message (not just a name swap), and warn the user about this risk when they ask for outreach. Sending can't be undone and everyone in the chat sees the poll: confirm the recipient, question and options with the user first unless they already gave them. Returns { to, status (sent or failed), recipient, message_id, question, options, allow_multiple, error? }: recipient is the chat the poll 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 +). If WhatsApp rejects the poll, the result is an error that still includes recipient and error.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "to": "<to>",
      "question": "<question>",
      "options": "<options>"
    },
    "name": "send_poll"
  }
}

Input 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).
optionsYesThe answers people can choose from, 2 to 12, all different, in the order to show them, e.g. ["Friday", "Saturday", "Sunday"].
questionYesThe poll's question, e.g. "Which day works for dinner?".
allow_multipleNoOptional. true lets each person pick as many options as they want; false or omitted allows one answer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / allow_multiple
      Added value: +{
      +  "description": "Optional. true lets each person pick as many options as they want; false or omitted allows one answer.",
      +  "type": "boolean"
      +}
  2. Added

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already flag this as a non-read-only, non-idempotent, open-world write, and the description adds real behavioral context beyond that: plan gating, refusal on a busy number, irreversible sending, visibility to everyone in the chat, ban risk for repeated outreach, and the confession that poll votes can't be read back. Held to 3 rather than higher because the annotations already carry the safety profile and much of the behavioral payload is defensive boilerplate about formatting and anti-spam that is not specific to polling.

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

Conciseness3/5

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

Purpose is front-loaded in the first clause, which is good, but the description runs very long for a four-parameter tool. A substantial block is generic WhatsApp Markdown advice ('never send tables, # headings, **double asterisks**') that has marginal value for poll questions and options, and the anti-spam paragraph is lengthy relative to the task, diluting the operationally important sentences about plan gating, ambiguity resolution and confirmation.

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?

With no output schema in the context, the description correctly spends words on the return shape: { to, status, recipient, message_id, question, options, allow_multiple, error? } and even documents the nested contact fields on `recipient` (name_source enumerations, canonical_jid, phone_jid/lid_jid, phone_display). It also states what the failure result looks like (an error that still carries `recipient`), which is exactly the completeness needed for a fire-and-forget write with no structured output.

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 this only earns credit for value beyond the schema. It does add some: `to` is tied to send_message's semantics with the ambiguity-resolution rule spelled out, `allow_multiple` gets a motivating example ('which days can you come?'), and the distinct-options constraint is restated. The `question` parameter itself gets no additional guidance beyond the schema's example.

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?

States a specific verb and resource ('Sends a WhatsApp poll') and immediately parenthesizes the shape of the artifact (a question with 2 to 12 tappable answer options) plus the scope (one person or group, from the user's number). This clearly distinguishes it from sibling send_message without requiring the schema to be opened.

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?

Explicit when-to-use with a concrete example ('ask the family group which day works for dinner'), an explicit prerequisite path (ambiguous contact name → call search_contacts first), explicit when-it-fails conditions (free plan refused, busy number refused), and explicit when-not guidance ('don't offer to count the votes' since results can't be read). Alternatives and exclusions are both named.

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.