Skip to main content
Glama

List WhatsApp Business Templates

wa_list_templates
Read-only

List the WhatsApp Business message templates of one of your Business (Cloud API) numbers, with each one's review status (APPROVED, PENDING, REJECTED — a rejected one carries Meta's rejected_reason). Use an APPROVED template's name and language with wa_send_message's template/template_language to start a conversation or message outside the 24-hour window, and supply its 'variables' count as template_variables, in order. Templates apply only to Business numbers, not personal linked-device numbers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
account_idYesthe Business (Cloud API) account whose templates to list, as returned by wa_list_accounts

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
refusalNopresent only when the call was declined
templatesNoevery message template with its review status; only APPROVED ones can be sent, with the name/language/variables to pass to wa_send_message

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedOutput schema / properties / refusal / properties / account_status
      Added value: +{
      +  "description": "when the number is not working: its status — starting, not_running, whatsapp_down, suspended, pairing, unlinked or locked",
      +  "type": "string"
      +}
    • addedOutput schema / properties / refusal / properties / account_status_reason
      Added value: +{
      +  "description": "the detail of account_status, e.g. no_egress, stopped, no_plan",
      +  "type": "string"
      +}
    • addedOutput schema / properties / refusal / properties / since
      Added value: +{
      +  "description": "when the number stopped working, RFC3339, when known",
      +  "type": "string"
      +}
    • addedOutput schema / properties / templates / items / properties / call_permission
      Added value: +{
      +  "description": "true when the template asks the customer to allow the business to call them (WhatsApp's call permission request)",
      +  "type": "boolean"
      +}
  2. Changed4 schema fields changed
    • addedOutput schema / properties / templates / items / properties / body
      Added value: +{
      +  "description": "the template's body text as Meta holds it, with its {{n}} variables",
      +  "type": "string"
      +}
    • addedOutput schema / properties / templates / items / properties / buttons
      Added value: +{
      +  "description": "one line per button, e.g. 'Quick reply: Yes' or 'Link: Shop → https://…'",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": [
      +    "null",
      +    "array"
      +  ]
      +}
    • addedOutput schema / properties / templates / items / properties / footer
      Added value: +{
      +  "description": "the template's footer, if any",
      +  "type": "string"
      +}
    • addedOutput schema / properties / templates / items / properties / header
      Added value: +{
      +  "description": "the template's text header, if any",
      +  "type": "string"
      +}
  3. Changed2 schema fields changed
    • changedOutput schema / properties / templates / description
      Previous value: -"the approved message templates, with the name/language/variables to pass to wa_send_message"New value: +"every message template with its review status; only APPROVED ones can be sent, with the name/language/variables to pass to wa_send_message"
    • addedOutput schema / properties / templates / items / properties / rejected_reason
      Added value: +{
      +  "description": "for a REJECTED template, Meta's reason code (e.g. INVALID_FORMAT, TAG_CONTENT_MISMATCH); fix the template and create it again under a new name",
      +  "type": "string"
      +}
  4. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds real behavioral context beyond them: the possible review statuses (APPROVED/PENDING/REJECTED) and that rejected templates carry Meta's rejected_reason. It also discloses the important limitation that templates only apply to Business numbers. What it does not address — pagination or whether results are cached — is minor for a listing tool.

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 scope are front-loaded in the first clause, and the second sentence carries only operational guidance. It is dense and long-ish, but each clause (statuses, rejected_reason, downstream usage, scope limit) contributes information rather than 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 single-parameter listing tool with an output schema, this description is complete: it explains what is listed, what the statuses mean, the account-type restriction, and how the result feeds wa_send_message. Nothing needed to invoke or use the tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the sole account_id parameter is fully documented in the schema, including that it comes from wa_list_accounts. The description restates the Business-account constraint but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 ('List the WhatsApp Business message templates') scoped to 'one of your Business (Cloud API) numbers', and the mention of review status and rejected_reason makes clear what comes back. An agent can distinguish it from wa_create_template and wa_delete_template without opening any 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?

Explicitly routes the agent forward: use an APPROVED template's name/language with wa_send_message's template/template_language for conversations outside the 24-hour window, and pass the variables count as template_variables in order. It also states a scope exclusion — templates apply only to Business numbers, not personal linked-device numbers.

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