Skip to main content
Glama
wuapidev

wuapi MCP server

Official
by wuapidev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Manage labels

manage_labels
DestructiveIdempotent

Create, edit, delete, and add or remove WhatsApp Business labels from chats and messages. For WhatsApp Business accounts only.

Instructions

WhatsApp Business labels on chats and messages: create or edit a label, delete it, and add it to or remove it from a chat or a message. WhatsApp Business accounts only; others answer not_supported. There is no endpoint that lists labels: they arrive in label.updated webhook events, and upsert creates one under an id you choose.

Actions:

  • upsert: Create the label with this id, or rename or recolor it. Returns the label.

  • delete: Delete the label. Needs confirm: true.

  • label_chat: Add the label to a chat.

  • unlabel_chat: Remove the label from a chat.

  • label_message: Add the label to a message, as the account that sent or received it.

  • unlabel_message: Remove the label from a message.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoThe label name. Required for `upsert`.
colorNoWhatsApp's label color index, 0 to 19. Default 0. Optional for `upsert`.
actionYesWhat to do. See the list of actions in the tool description.
chatIdNoThe chat: a contact as E.164 with + (`+584241112233`) or `lid:<digits>`, or a group id (`...@g.us`). Required for `label_chat`, `unlabel_chat`.
confirmNoMust be true. The label is removed from every chat and message. Only set it after the user asked for this or agreed to it. Required for `delete`.
labelIdNoThe label id. `upsert` creates the label under this id when there is none. Required for every action.
accountIdNoThe wuapi account id of the linked number to act as (from list_accounts). Required for `upsert`, `delete`, `label_chat`, `unlabel_chat`.
messageIdNoA wuapi message id (from list_messages, a send tool, or a webhook). Required for `label_message`, `unlabel_message`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety bar is partly met structurally. The description adds real value beyond them: non-Business accounts answer `not_supported`, delete requires `confirm: true`, and deletion removes the label from every chat and message.

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?

A front-loaded one-sentence summary is followed by a scannable action list, so an agent can locate the relevant action quickly. It is slightly long, but every line maps to a distinct action or constraint, so little is wasted.

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 an 8-parameter multi-action tool with no output schema, the description covers the key gaps: action-parameter coupling, the confirm requirement, the Business-only limit, and how labels get listed. It even notes that upsert returns the label, partially compensating for the missing output schema.

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%, so every parameter (including action, labelId, confirm, chatId, messageId) is already documented in the schema. The description reinforces the upsert-creates-under-id semantics, but adds no format or validation detail beyond what the schema provides; 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?

The description names a specific resource (WhatsApp Business labels on chats and messages) and enumerates the exact operations via the actions list. There is no sibling label tool, so it is trivially distinguishable, and the WhatsApp Business-only restriction is stated upfront.

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

Usage Guidelines4/5

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

Each action is given a one-line when-to-use gloss (upsert to create/rename/recolor, delete to remove, label/unlabel for chat vs message). It also proactively explains the non-obvious workflow: there is no list endpoint and labels arrive via label.updated webhooks. No explicit alternative-tool comparison, but no sibling overlaps.

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