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

Beyond the destructiveHint annotation, the description discloses meaningful consequences and prerequisites: accepting invitations is required before access, removing yourself leaves the group, ownership must be transferred before an owner can leave, and delete closes the group for everyone. This is valuable behavioral context consistent with destructiveHint=true. It does not cover auth or rate-limit traits, keeping it short of a 5.

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?

Four short sentences, front-loaded with the purpose before the action-specific constraints. Efficient with little waste, though the action-condition sentences are somewhat clipped and telegraphic.

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?

For a multi-action tool with no output schema, the description covers some actions (accept, remove, delete) but leaves invite, decline, rename, describe and role unexplained. There is no return-value or result guidance and the action enum is not declared in the schema, so an agent must infer behavior for several operations.

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 75%, so the schema already documents value, action and account. The description's action words (invite, remove, role, delete) loosely map to those parameters but add no syntax or format detail, and the required 'id' parameter has an empty schema description that the prose does not compensate for. Baseline 3 is appropriate.

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?

The description names a specific domain of operations ('invitations, membership and roles') for the groups_update tool, distinguishing it from the read/list/create siblings. However, it presents itself as a broad umbrella rather than stating the concrete action-based nature (invite/accept/decline/remove/role/rename/describe/delete) that the schema actually exposes.

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?

It gives conditional guidance for specific actions ('Accept invitations before accessing a group', 'owners must transfer ownership first', 'Delete closes the group for everyone'), which implies when certain actions apply. But it never contrasts with alternatives or states clearly when to reach for this tool over groups_create/groups_read, leaving routing to inference.

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