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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds behavior beyond that: passing group_id changes the shape of the answer (it also carries the community's rules page titles), which is a non-obvious side effect of an optional parameter on an otherwise read-only list tool.

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 the core listing behavior, then the group_id variant, then downstream usage. Dense but each clause carries information; the cross-tool recipient syntax clause is the only part that feels slightly bolted on, though it is genuinely useful.

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?

No output schema exists, and the description compensates by enumerating the returned fields and stating that rules come back as page titles. For a read-only, three-parameter list tool with full schema documentation, this is nearly complete; only edge behavior (empty membership, invalid group_id) is unaddressed.

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 baseline is 3, but the description adds meaning the schema does not carry: that the returned ids are the inputs for posts.publish and the 'skool:user:<user id>@<community id>' recipient syntax for messages.send. account_id and in_workspace are left entirely to 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?

Names a specific verb and resource ('List the Skool communities (groups)') and scopes it precisely to communities the connected account belongs to, then enumerates the returned fields (id, name, display name). It also distinguishes the two modes of the tool: plain listing versus listing-plus-rules when group_id is supplied.

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?

Goes beyond stating purpose by telling the agent what to do with the result: 'Use the ids as posts.publish's destination' and the exact recipient format for messages.send, plus 'read them before posting' when fetching rules. It does not name an alternative tool to avoid, but no sibling offers competing Skool group listing, so the guidance is effectively complete.

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