Skip to main content
Glama

audiences

Create and manage reusable contact lists, add contacts with custom variables, and target them in WhatsApp messages or campaigns.

Instructions

Reusable contact lists used as targets for messages and campaigns. Available actions:

  • list: list audiences

  • create: create a new audience by name

  • get / update / delete: standard CRUD on an audience

  • append_contacts: add contacts (to + optional variables) to an audience

  • update_contact / remove_contact: edit or remove a single contact within an audience

Phone format: to must be in international format (e.g. +14155551234). JID form (12345@c.us) is rejected here. Variables: each key on variables becomes a {key} token usable in campaign templates (case-insensitive). Custom tokens override built-ins: setting variables.firstName='Doug' makes {firstName} resolve to Doug instead of the WA profile name. Built-ins always available even without variables: whatsappname, displayname, phone, mobile.

Examples:

  • create: 'create an audience called Leads'

  • append_contacts: 'add +972544325389 to the Leads audience with firstName=Doug, product=Premium'

Input Schema

NameRequiredDescriptionDefault
toNo
nameNo
skipNo
limitNo
actionYes
contactsNo
variablesNo
contact_idNo
audience_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/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 real behavioral detail: phone numbers must be international format and 'JID form (12345@c.us) is rejected here', variables become `{key}` template tokens, custom tokens override built-ins, and four built-in tokens always resolve. These are non-obvious runtime semantics an agent could not infer. It is silent, though, on what delete does to stored contacts, permissions, and pagination behavior.

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?

The structure is front-loaded and scannable: purpose sentence, action list, then constraint notes, then examples. Nothing is redundant, though the examples slightly restate what the action list already conveys.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, 8-action tool with no annotations and no output schema, the description covers the hardest semantics (token variables, phone validation) but omits pagination parameters, how `contact_id`/`audience_id` are obtained, and the consequences of delete. An agent can call the main flows correctly but would guess on the rest.

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 0% across 9 parameters, so the description must compensate and does so for several: `to` format, `variables` substitution semantics, `name` on create, and the nested contacts shape ('to + optional variables'). It leaves `skip`, `limit` (pagination), `contact_id`, and `audience_id` entirely unexplained, so roughly half the parameters remain undocumented in both schema and description.

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 opening line names the resource and its role ('Reusable contact lists used as targets for messages and campaigns'), and the action list gives a concrete verb inventory. An agent knows exactly what domain this covers, though it doesn't distinguish the tool from siblings like contacts or campaigns.

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?

Enumerating actions with one-line glosses ('list audiences', 'create a new audience by name') tells an agent which action to pick, and the examples illustrate two common flows. However, there is no guidance on when to use this tool versus contacts or campaigns, and no prerequisites or exclusions are stated.

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