Skip to main content
Glama

list_groups

List WhatsApp groups a number belongs to, returning each group's identifier. Filter by search term and limit results to find specific groups.

Instructions

Lista os grupos de que o número participa, com o identificador de cada um.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
buscaNo
limiteNo
instanceNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations, the description bears the transparency burden. 'Lista' signals a read-only listing, and the description adds scope and output detail (group identifier), but it does not mention authentication requirements, rate limits, pagination, or ordering behavior. Still, it is not misleading and communicates the core 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 description is a single front-loaded sentence with no filler, and every clause adds meaning ('groups', 'the number participates in', 'with the identifier'). It is concise, though slightly under-specified in other dimensions.

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

Completeness2/5

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

For a tool with three parameters, no annotations, and no parameter descriptions, a one-sentence description is not enough for fully informed invocation. The existence of an output schema covers the return shape, but context about how parameters interact and how this tool relates to sibling chat/group tools is missing.

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

Parameters1/5

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

Schema description coverage is 0% and the description says nothing about 'busca', 'limite', or 'instance'. A caller cannot learn how to filter, cap results, or select an instance from either the description or the schema's property titles. The description therefore does not compensate for the missing parameter documentation.

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 description uses a specific verb ('Lista'), names the resource ('grupos'), and scopes it to 'o número participa', with the added detail that each group identifier is returned. This is clear, but it does not explicitly distinguish list_groups from the sibling list_chats, so it falls one step short of a 5.

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?

The phrase 'de que o número participa' implies the tool is meant for retrieving groups associated with the WhatsApp number, so the use case is reasonably clear. However, it never names alternatives or explains when to prefer list_groups over list_chats or get_chat_info, leaving selection to inference.

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