Skip to main content
Glama

Add, remove, promote or demote group members

manage_group_participants
Destructive

Change WhatsApp group membership by adding, removing, promoting, demoting, or approving/rejecting participants; requires group admin rights.

Instructions

Changes group membership: add, remove, promote (to admin), demote, or approve/reject join requests. The instance must be a group admin. 'remove' kicks people out and cannot be undone automatically; 'add' notifies the people added, so only add people who agreed.

Input Schema

NameRequiredDescriptionDefault
actionYes
group_jidYesGroup JID ending in @g.us.
instance_idNoZapZap instance id (a connected WhatsApp number). Optional when ZAPZAP_INSTANCE_ID is configured; otherwise call list_instances first.
participantsYesPhone numbers with country code, digits only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is known. The description adds real value beyond that: the admin authorization requirement, the irreversibility of remove, and the side effect that add notifies the affected people — none of which the annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: capability and actions first, then preconditions and per-action caveats. Every clause (admin requirement, undo warning, notification warning) carries operational weight with no 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 a destructive, non-idempotent mutation tool with no output schema, the description covers authorization, side effects, and reversibility. It stops short of noting partial-failure behavior for batches of up to 50 participants or what the response contains, which an agent composing a large removal would want.

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

Parameters4/5

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

Schema coverage is 75% and the schema documents group_jid, instance_id, and participants well, but the action enum has no per-value descriptions in the schema. The description supplies that missing semantic layer by spelling out promote/demote/approve/reject meanings, which is exactly the compensation needed.

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?

Opens with a specific verb+resource ('Changes group membership') and enumerates all six supported actions, including the parenthetical 'promote (to admin)' that clarifies an ambiguous enum value. It is clearly distinguishable from siblings like create_group, get_group_info, and list_groups, which read rather than mutate membership.

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?

Gives a hard precondition ('The instance must be a group admin') and per-action guidance on when to be cautious with add and remove. It does not explicitly route to an alternative tool (e.g. use create_group for new groups), so it falls short of full when/when-not coverage.

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