Skip to main content
Glama

manage_whatsapp_campaigns

Universal WhatsApp campaign management tool that handles all campaign operations through action-based parameters. Supports search, create, update, start, stop, and delete operations for WhatsApp bulk messaging campaigns. Perfect for comprehensive WhatsApp marketing automation.

What a campaign sends depends on the number. Its connector, reported by get_whatsapp_devices and health_check, says which kind it is: cloud for WhatsApp Cloud API, web for a number linked by QR.

  • WhatsApp Cloud API (WABA) numbers: a pre-approved template is required, and it only reaches phone numbers, never groups. Pass template { name, language } and give each recipient the values its variables need. Read the template first with list_whatsapp_templates: every variable it reports has a location (header, body or buttons) and, for buttons, a buttonIndex starting at 0. Send each value with its component, and for a button variable use button_url_N or button_copy_code_N with that index.

  • Numbers linked by QR: a message, optionally with a file. Personalize it with placeholders: {{ name }} is the recipient's name, {{ phone }} their number, and each key in a recipient's variables fills {{ key }}. For example message "Hi {{ name }}, your order {{ order }} has shipped" with variables [{ key: "order", value: "A-1043" }]. Write keys and placeholders in lowercase. A placeholder a recipient has no value for disappears from their message; {{ order | on its way }} prints the text after the bar instead.

To send it: create with activate true, which needs settings.date and at least one recipient, or create first and then start, which asks for the same two. If activation fails during create, the campaign is deleted and you have to create it again.

Recipients: pass them on create, up to 2000 per request. To add or remove them afterwards use manage_whatsapp_campaign_contacts. The total a campaign can hold depends on the plan, from 100 on trial to 2000.

What it will cost: before launching a template campaign, estimate_cost gives the price Meta lists per message for each country, in costs: one line per country (or dialling code) with the category of the template and how many messages go there.

Payment problems: when Meta reports one on a Cloud API number's WhatsApp Business account, the templates it sends are rejected (error 131042). A Cloud API number that needs reconnecting stops the same way, because its messages fail until it is reconnected. The three ways to send a campaign (create with activate true, update with activate true, and the start action) then refuse, say why and write nothing. Tell the user, and only repeat the call with confirmPaymentIssue true if they say the payment is already fixed or want to send anyway.

Things that do not undo: delete removes a campaign for good, and stop does not recall messages already handed to WhatsApp.

Input Schema

NameRequiredDescriptionDefault
fileNoUploaded file ID. On a template campaign this is the header media, and only for a template whose header is an image, video or document: on a template without a media header the API sends a header the template does not have and Meta rejects it. Upload the file first with upload_whatsapp_file_from_url
nameNoCampaign name (required for create action)
pageNoResults page number (for search action)
sizeNoResults page size (for search action, max 100)
afterNoFilter campaigns created after this date (for search action)
costsNoFor estimate_cost: one line per country of the recipients, with the template category and the number of messages. Up to 100 lines
groupNoFilter campaigns by group IDs (for search action)
ownerNoFilter by owner user IDs (for search action)
phoneNoFilter campaigns by recipient phone numbers (for search action)
actionYesAction to perform on WhatsApp campaigns
beforeNoFilter campaigns created before this date (for search action)
deviceNoWhatsApp device ID (required for create action)
statusNoFilter campaigns by status (for search action)
messageNoCampaign message, for numbers linked by QR. On a WhatsApp Cloud API number use template instead. Personalize it with {{ name }}, {{ phone }} and {{ key }} for each key in the recipients' variables
activateNoStart the campaign right after creating it. Needs settings.date and at least one recipient; without them the campaign is created and left as a draft
contactsNoCampaign recipients, for the create action only. Max 2000 per request, and the total a campaign can hold depends on the plan (100 on trial, 500 to 2000 otherwise). To add or remove recipients later use manage_whatsapp_campaign_contacts
settingsNoCampaign delivery settings (for create/update actions)
templateNoPre-approved template to send. Required on WhatsApp Cloud API numbers, and not accepted on numbers linked by QR
campaignIdNoWhatsApp campaign ID (required for get, update, start, stop, delete actions)
unsubscribeNoUnsubscribe settings (for create/update actions)
confirmPaymentIssueNoOnly after telling the user that Meta reports a payment problem on the number, or that it needs reconnecting: true to activate or start the campaign anyway, because they say it is already fixed or reconnected, or want to send regardless

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: activation failure during create deletes the campaign, delete is permanent, stop does not recall already-sent messages, plan-based recipient caps, and a detailed payment-issue/error-131042 flow gated by confirmPaymentIssue. This is unusually rich behavioral disclosure.

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?

Purpose is front-loaded in the first sentence and the body is organized by scenario (sending, activation, recipients, cost, payment, irreversibility). It is long and repeats some placeholder/component detail already in the schema, keeping it from a 5.

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 21-parameter tool with nested objects and no output schema, the description covers every consequential path an agent must navigate—number type routing, activation prerequisites, cost estimation, payment failures, and destructive operations—leaving nothing essential unexplained.

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, and the description adds real meaning on top: placeholder syntax ({{ name }}, {{ key }}, fallback via the bar), template component/buttonIndex mapping, and speed semantics. It stops short of full coverage of every nested field (e.g., unsubscribe actions), so a 4 rather than 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?

The opening sentence states a specific resource (WhatsApp campaigns) and enumerates all supported operations (search, create, update, start, stop, delete), so the agent knows exactly what the tool does. It also points to siblings like manage_whatsapp_campaign_contacts and list_whatsapp_templates for adjacent tasks, differentiating its scope.

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 explicit branching guidance: cloud (WABA) numbers require a pre-approved template and reach phones only, while QR-linked numbers take a message with optional file. It spells out the two activation paths (create with activate true vs create then start), when to call estimate_cost, and redirects recipient edits to a sibling tool.

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