Skip to main content
Glama

WhatsApp Business API by Wassenger

manage_whatsapp_web_forms

Destructive

Build and manage web forms: forms customers fill in the browser from a short link sent in a WhatsApp chat, with the answers coming back as structured submissions. For WhatsApp Forms (Meta WhatsApp Flows, native in-chat forms on WhatsApp Business API numbers) use send_whatsapp_flow and list_whatsapp_flows instead.

Actions: list, get, create (blank, from a template, or from a definition), update (name, settings, numbers, or the whole draft), edit (operations on the draft, as { type: "addBlock", step, blockType, label, ... }), publish, archive, restore, duplicate, delete, versions, version (one published version with its answers JSON Schema), templates (the gallery), metrics, set_og_image (your own link preview image: an https URL or a base64 PNG/JPEG up to 1 MB, cropped to 1200×630), remove_og_image (back to the automatic one), set_public (a standing public link anyone can open, waform.app/m/..., bound to one number: for ads, bio links and QR codes), unset_public (turn it off).

Edits change the draft only: a published form keeps serving its live version until the next publish. publish, archive, delete and an edit with confirm=true answer a preview and a confirmToken first: show the preview to the user and call again with the token once they approve. To send a form, use send_whatsapp_web_form.

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": {
      "action": "<action>"
    },
    "name": "manage_whatsapp_web_forms"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNometrics: last day, YYYY-MM-DD (UTC)
opsNoedit: draft operations, applied all or none, e.g. [{ "type": "addBlock", "step": "details", "blockType": "email", "label": "Your email", "required": true }]
urlNoset_og_image: https URL of a PNG or JPEG
fromNometrics: first day, YYYY-MM-DD (UTC)
langNotemplates: language of the gallery (es, en, pt, fr, it, de)
nameNocreate, update, duplicate: form name
pageNoPage, from 0
sizeNoRows per page (default 25, max 100)
slugNoset_public: the end of the public link, e.g. acme-booking
sortNolist: order (newest first by default)
imageNoset_og_image: the image as base64 or a data URI
actionYesWhat to do
deviceNolist: forms these numbers may send. metrics: only these numbers
fieldsNoReturn only these dot-paths, e.g. ["id", "name", "status"]. Overrides verbosity
formIdNoWeb form ID (id from the list action)
searchNolist: text in the form name
statusNolist: only forms in these states
captchaNoset_public: ask visitors for an invisible check when the platform has one configured (default true)
confirmNoedit: true to rename or remove a key a published version holds (the API refuses those edits otherwise). It answers a preview and a confirmToken first
devicesNocreate, update: numbers allowed to send the form (all when empty)
groupByNometrics: daily rows, or totals only
versionNoversion: the published version number
languageNocreate, update: form language, e.g. en, es
settingsNocreate, update: settings such as { link: { ttlHours, afterSubmit }, submit: { successTitle, successText }, crm: { mappings, contactLabels, timelineCard } }
templateNocreate: template id from the templates action
verbosityNosummary (default): the fields needed most; standard: more context; full: everything the API returns
definitionNocreate, update: a whole form definition (format 1). Prefer template on create and edit afterwards
descriptionNocreate, update: internal description
confirmTokenNoToken from the preview, sent back once the user approved the change
publicDeviceNoset_public: the number the public link is bound to; its appearance brands the page and it receives the leads
idempotencyKeyNocreate: your unique key for this form, 6 to 36 characters. Reuse it when retrying: the API answers the form already created
deleteSubmissionsNodelete: also delete the form's submissions, links and counters

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

Beyond the annotations (destructiveHint=true, openWorldHint=true, non-idempotent), the description discloses genuinely non-obvious behavior: edits mutate only the draft while a published form keeps serving its live version until the next publish, and publish/archive/delete plus confirm=true edits return a preview and confirmToken that must be shown to and approved by the user before re-calling. It also states image constraints (https URL or base64 PNG/JPEG up to 1 MB, cropped to 1200×630) and that a public link is bound to one number. It stops short of anything about rate limits or what a preview payload contains.

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 and sibling routing are front-loaded, then actions, then the draft-vs-published and confirm-token rules. The action sentence is a long enumeration but each item is short and scannable; the parenthetical clarifications (e.g. "back to the automatic one", "the gallery") are compact rather than redundant.

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 32-parameter, nested-object, destructive tool with no output schema, the definition covers the risky parts: confirmation flow, draft isolation, deletion side effects implied by delete, and public-link binding. It does not explain the verbosity/fields projection behavior or the metrics date-range semantics, though the schema documents those.

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 description coverage is 100%, so the schema already carries per-parameter meaning and the baseline is 3. The description still adds value on top: it spells out the edit operations shape with a concrete addBlock example, the OG image size/format ceiling, and the semantics of a public link (standing public URL bound to one number, intended for ads, bio links, QR codes).

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 first sentence states a specific verb+resource (build and manage web forms) and defines the mechanism precisely: browser forms reached via a short link sent in a WhatsApp chat, with answers returning as structured submissions. It then explicitly carves out the sibling territory (Meta WhatsApp Flows via send_whatsapp_flow / list_whatsapp_flows) and the send path (send_whatsapp_web_form), so an agent can route without opening a schema.

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 names two alternatives with the condition that selects each: use send_whatsapp_flow / list_whatsapp_flows for native in-chat flows, and send_whatsapp_web_form to dispatch an existing form. The action enumeration further implies which verb applies to which lifecycle stage (versions/version/templates/metrics vs create/update/edit/publish), leaving little to inference.

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.