Skip to main content
Glama
wuapidev

wuapi MCP server

Official
by wuapidev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Manage favorite stickers

manage_favorite_stickers
Idempotent

List, add, remove, or fetch files for WhatsApp favorite stickers. Syncs the star tab with the phone.

Instructions

The account's favorite stickers: the star tab of WhatsApp's sticker picker, which WhatsApp keeps in sync with the phone. List them, get one's file, favorite a sticker from a message or an uploaded WebP file, or remove one. Adding and removing change the list on the phone too.

Actions:

  • list: The favorites, newest first, from what wuapi stored (no call to WhatsApp). Each has media.url and media.downloaded; animated and emojis are null until its file was fetched.

  • get_file: A direct URL to one favorite's file that needs no API key. Fetches the file from WhatsApp the first time, which needs the account ready.

  • add: Favorite a sticker: pass messageId or uploadId, one of them. A sticker that is a favorite already is returned as is.

  • remove: Take a sticker out of the favorites. It can be favorited again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoPage size, 1 to 100. Default 20. Optional for `list`.
actionYesWhat to do. See the list of actions in the tool description.
cursorNo`nextCursor` from the previous page, to get the next one. Optional for `list`.
uploadIdNoA WebP file uploaded with upload_file (`mimeType: image/webp`, at most 2 MB) to favorite. Optional for `add`.
accountIdNoThe wuapi account id of the linked number to act as (from list_accounts). Required for every action.
messageIdNoA sticker message of this account to favorite (from list_messages or a webhook). Optional for `add`.
stickerIdNoA favorite sticker's id, from the `list` action. Required for `get_file`, `remove`.
idempotencyKeyNoOptional. Reuse the same key when retrying this exact call: within 24 hours wuapi returns the first result instead of doing it twice. Optional for `add`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the annotations (idempotent, non-destructive, open-world), the description discloses meaningful behavior: add/remove are synced to the phone, list reads stored data without contacting WhatsApp, get_file lazily fetches on first use, and re-adding an existing favorite is a no-op. These are non-obvious operational traits that the structured fields do not convey.

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 summary is front-loaded, and the per-action bullet structure makes the variants scannable. It is somewhat long, but nearly every sentence carries operational detail rather than filler.

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, no-output-schema tool, the description covers per-action behavior and even sketches the list return shape (media.url, media.downloaded, animated/emojis null until fetched). It is close to complete, with only minor gaps around error cases.

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 the schema already documents all 8 parameters in detail. The description adds the useful mutual-exclusion constraint for add (messageId or uploadId, 'one of them'), but otherwise largely restates what the schema provides, so the baseline of 3 is appropriate.

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 states a specific resource (favorite stickers / the star tab of the sticker picker) and enumerates the exact operations (list, get_file, add, remove). It distinguishes itself from superficially similar siblings like star_message by scoping to favorited stickers specifically.

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 carries clear context: list is local-only (no WhatsApp call), get_file needs the account ready, add requires either messageId or uploadId. It clearly routes usage per action, though it does not explicitly compare against siblings such as star_message or send_media.

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