Skip to main content
Glama

manage_whatsapp_team

Comprehensive WhatsApp team management tool supporting all team operations. Perfect for managing team member lifecycle, device access, and role assignments. Supports all WhatsApp team operations through a unified action-based interface.

Available actions:

  • search: Search and list team members with filtering options

  • get: Get detailed information about a specific team member by ID

  • create: Create a new team member and grant them access to a WhatsApp device (requires device, email, displayName, password, role and color)

  • update: Update an existing team member's name, email, password, role or color

  • delete: Delete one or more team members from the account, choosing what happens to their assigned chats

  • grant_access: Grant an existing team member access to a WhatsApp device

  • revoke_access: Revoke a team member's access to a WhatsApp device, choosing what happens to their assigned chats

Notes:

  • New team members are always created against a specific WhatsApp device and are granted access to it immediately.

  • grant_access and revoke_access operate on a single team member at a time.

  • delete, and revoke_access when chatAction is "reassign", require reassignTo.

Input Schema

NameRequiredDescriptionDefault
idsNoRestrict search results to these team member IDs
pageNoResults page number
roleNoFilter by team member role for search, or the role to assign for create and update
sizeNoMaximum number of results per page
colorNoTeam member color (required for create, optional for update)
emailNoTeam member email address (required for create; may be used instead of userId to identify the member for delete and revoke_access)
forceNoDelete team members even when they still have access to active WhatsApp devices (for delete action)
queryNoFree text search over team member name and email (for search action)
actionYesAction to perform on WhatsApp team members
deviceNoWhatsApp device ID (required for create, grant_access and revoke_access actions; optional filter for search)
inviteNoSend an invitation email to the new team member (for create action)
removeNoAlso delete the team member from the account, not just from this device (for revoke_access action)
statusNoFilter by team member status (for search action)
userIdNoTeam member ID (required for get, update, grant_access and revoke_access actions)
userIdsNoArray of team member IDs to delete (required for the delete action, max 10)
passwordNoTeam member password (required for create, optional for update)
exceptIdsNoExclude these team member IDs from search results
chatActionNoWhat to do with the chats assigned to the removed team memberunassign
loginAfterNoOnly team members whose last login is after this ISO 8601 date and time
reassignToNoTeam member ID to reassign chats to (required when chatAction is "reassign")
displayNameNoTeam member display name (required for create)
loginBeforeNoOnly team members whose last login is before this ISO 8601 date and time
onlineAfterNoOnly team members last seen online after this ISO 8601 date and time
onlineBeforeNoOnly team members last seen online before this ISO 8601 date and time

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations present, the description carries the full burden and does disclose the destructive surface: delete removes team members and lets the caller choose what happens to their chats via chatAction, revoke_access with 'remove' deletes the member from the account entirely, and 'force' signals a guard that would otherwise block deletion. It stops short of stating permission requirements or whether deletion is reversible.

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?

Front-loaded action list with per-action one-liners plus a tight Notes block is well suited to a multi-action dispatcher. The opening two sentences are largely redundant with each other ('comprehensive team management' / 'supports all team operations through a unified action-based interface'), costing a little efficiency.

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 24-parameter, action-dispatch tool with no output schema and no annotations, the description covers action semantics, key required-field bundles, and destructive side effects. It does not describe result shape, pagination behavior for search (page/size), or the meaning of status filters, leaving some gaps an agent may need.

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 100%, so the baseline is 3, but the description adds cross-parameter dependency semantics the schema only states locally: reassignTo is required when chatAction is 'reassign', and create requires device/email/displayName/password/role/color as a bundle. That conditional logic is genuine added value beyond the per-field descriptions.

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 the specific resource (WhatsApp team members) and enumerates all seven supported actions verb-by-verb, so the agent knows exactly what scope this tool covers. No sibling tool handles team membership, so differentiation is achieved by the explicit domain statement rather than by naming an alternative.

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 paired with its intent (e.g. 'grant_access: Grant an existing team member access to a WhatsApp device'), and the Notes section adds applicability constraints such as grant_access/revoke_access operating on one member at a time and delete/revoke_access requiring reassignTo under 'reassign'. There is no explicit when-not-to-use guidance or routing to a sibling, which keeps it below a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources