Create a WhatsApp group

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

Annotations only tell the agent this is a non-read-only, non-idempotent, open-world write. The description adds genuinely operational context: the calling instance becomes admin, participants are added and notified immediately, the 50-participant cap, and the concrete ban/report risk. This is exactly the kind of behavior that is invisible in structured fields.

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

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

Three tight sentences, front-loaded with the action and constraints, followed by the safety rationale. Every sentence earns its place and there is no redundant restatement of structured fields.

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

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

There is no output schema, and the description does not say what is returned (e.g., group id/JID) on success or what happens with invalid numbers. Otherwise it is complete for a mutation tool: constraints, side effects, and risk are all covered.

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

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

Schema coverage is 100%, so the baseline is 3. The description contributes meaning beyond the schema by explaining that instance_id (the instance number) becomes the group admin, and it reinforces the participant limit and name length constraints in operational terms. A small gap remains around phone-number formatting, which is covered only by the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource ('Creates a group with the given participants') and immediately discloses the key side effect that the instance number becomes admin. It is clearly distinguishable from siblings like list_groups, get_group_info, and manage_group_participants.

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

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

Provides strong situational guidance around participant consent ('only add people who agreed') and the ban risk of unsolicited adds. It does not explicitly compare against alternatives such as manage_group_participants or state prerequisites like needing a connected instance, 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.