List groups

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

Annotations already cover read-only/idempotent/non-destructive, so the bar is lower; the description still adds real context: a hard cap of 50 results, the role vocabulary (admin/moderator/member/pending), and the caveat that a pending group shows no posts or members yet. It stops short of saying what happens past 50 groups (no cursor/offset described).

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?

Front-loaded with what is returned and the cap, then field semantics, then the downstream usage hint. Slight redundancy between the lead fragment 'Skool groups of your account' and 'Returns up to 50 Skool groups of your account', but no sentence is wasted.

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 document the meaningful returned fields (role, members count origin, price, pending state). The gap is that it tells the agent to pass 'group' to other tools without describing that identifier's form, which matters for chaining.

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?

Zero parameters, so the baseline of 4 applies; there is nothing parameter-level for the description to compensate for.

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?

States a specific verb+resource: returns up to 50 Skool groups tied to the account, scoped to owned/joined/pending. It delineates scope well but never names the obvious siblings (get_group for one group, discover_groups for finding new ones), so the agent must infer the boundary.

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 one concrete downstream instruction: 'Use group as the group parameter of the other tools,' which is genuinely useful routing. However there is no explicit when-to-use-this-vs-alternative guidance against discover_groups or get_group, so the choice is only implied.

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