Skip to main content
Glama
Sign In
Arsel MCP Server

Arsel MCP Server

Official
by Arsel-SA
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List WhatsApp Templates

list-whatsapp-templates
Read-onlyIdempotent

List an organization's WhatsApp message templates with approval status, newest first, and filter by name, status or category. Use it to check which templates are approved before starting a conversation.

Instructions

List the organization's WhatsApp message templates with their approval status, newest first, whether they were created here, in the dashboard or imported from Meta. WhatsApp only lets a business start a conversation with an approved template. parameters names the placeholders a send must fill. Don't read ids or timestamps back to the user unless they ask for them.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list-whatsapp-templates"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoExact template name, e.g. order_shipped.
afterNoCursor for the next page: the `id` of the last item on this page. Cannot be combined with `before`.
limitNoItems per page, 1-100. Defaults to 20.
beforeNoCursor for the previous page: the `id` of the first item on this page.
statusNoOnly templates in this status.
categoryNoOnly templates in this category.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, and the description adds real context on top: default sort order (newest first), the operational meaning of the status field, what `parameters` represents, and an output-presentation rule about not surfacing ids or timestamps unprompted. No pagination behavior is disclosed, but cursors are documented in the schema.

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?

Three sentences, front-loaded with the resource and ordering, each carrying distinct information (subsetting scope, status semantics, output presentation). Slightly wordy in the 'created here, in the dashboard or imported from Meta' clause but it earns its place by explaining a field the agent will see.

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?

With six optional filters, no output schema, and full schema description coverage, the description does the right extra work: it explains ordering, the status-to-sendability relationship, and what the returned `parameters` means. A brief note on scope (organization-wide) or pagination would close the remaining gap.

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 description coverage is 100%, including enum values and cursor semantics, so the schema carries the parameter burden and the baseline of 3 applies. The description adds no input-parameter detail beyond what the schema already says, only clarifying a response field (`parameters`).

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?

States a specific verb and resource ('List the organization's WhatsApp message templates') plus the ordering ('newest first') and the source dimension (created here, dashboard, or imported from Meta). It is clearly distinct from generic 'list-templates' by scoping to WhatsApp, though it never names a sibling to route against.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied rather than stated: 'WhatsApp only lets a business start a conversation with an `approved` template' tells the agent why approval status matters before a send, but there is no explicit when-to-use/when-not guidance and no pointer to get-whatsapp-template or create-whatsapp-template for adjacent needs.

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