Skip to main content
Glama
Sign In
Arsel MCP Server

Arsel MCP Server

Official
by Arsel-SA
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Update WhatsApp Template

update-whatsapp-template
Destructive

Replace a WhatsApp template's content and resubmit it to Meta for review; approved templates return to pending and cannot be sent until approved again.

Instructions

Replace a WhatsApp template's content and resubmit it to Meta. components is the whole new content, not a patch: read the current one with get-whatsapp-template first. Name, language and category cannot be changed.

The template returns to pending, and only approved templates can be sent, so editing an approved template takes it out of use until Meta approves it again. Meta also limits edits of an approved template to one per 24 hours and ten per 30 days. Before calling you MUST show the user the new content and confirm.

Only approved and rejected templates can be edited. Authentication templates and templates adopted from Meta's library cannot.

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": {
      "id": "<id>",
      "components": "<components>"
    },
    "name": "update-whatsapp-template"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe WhatsApp template id.
componentsYesThe template content in Meta's component format, with `type`, `format` and button `type` in uppercase. Placeholders are named in lowercase snake_case, e.g. `{{first_name}}`: numbered ones such as `{{1}}` are refused, and a name can be used in the header or the body, not both. Example: [{"type":"HEADER","format":"TEXT","text":"Your order"},{"type":"BODY","text":"Hi {{first_name}}, order {{order_id}} has shipped."},{"type":"FOOTER","text":"Acme Store"},{"type":"BUTTONS","buttons":[{"type":"URL","text":"Track","url":"https://example.com/track"}]}]

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructive=true and idempotent=false, and the description adds substantial context beyond that: the template reverts to pending, an approved template goes out of use until re-approval, and Meta enforces one edit per 24 hours and ten per 30 days. The partial-replace semantics of components and the required confirmation are also spelled out.

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

Conciseness5/5

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

Three tight paragraphs: what happens, what the side effects and limits are, then eligibility rules. The read-first instruction and the confirmation requirement are front-loaded rather than buried, and no sentence is filler.

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 destructive, non-idempotent mutation with two required parameters and no output schema, the description supplies everything an agent needs: the prerequisite read, the state transition to pending, the rate limits, eligibility constraints, and the human-confirmation gate. Nothing material is missing.

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 adds real meaning the schema does not: components is the whole new content rather than a patch, and name, language and category are immutable. It stops short of explaining individual component fields, which the schema already handles 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 description opens with a precise verb+resource: replace a WhatsApp template's content and resubmit it to Meta. It is unambiguous what object is being modified, but it does not explicitly differentiate itself from the sibling update-template, leaving the agent to infer that this one is WhatsApp-specific.

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 preconditions and exclusions are all present: only approved and rejected templates can be edited, authentication templates and Meta-library templates cannot, and get-whatsapp-template must be called first to read the current content. The mandatory user-confirmation step is stated outright, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools