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

With no annotations supplied, the description carries the full behavioral burden and does so: it enumerates the default return shape field by field, explains role-dependent fields (org, role) and their permission consequences (viewer cannot write, reporter can only create_bug/update_bug), and discloses that the icon base64 in metadata is always stripped. The only minor omission is pagination or result-size behavior, which is not material for an unscoped list.

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?

It is front-loaded with purpose and the "use this first" routing before the detail, and nearly every clause carries information. It is a single dense paragraph, though, and the field enumeration plus role rules would scan faster as short bullets; a few listed fields (nodeCount, seasonCount, nowSeasonLabel) are recited without added interpretation.

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, so the description must describe returns, and it does so thoroughly, including the summary/full split, role-conditional fields, and the wikiCount meaning. Combined with only one optional parameter, an agent has everything needed to call this correctly and interpret the response.

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 already 100%, but the description goes well beyond the enum labels by explaining what summary actually contains versus what full adds (seedMeta with goal, endDate, budget, audience; typeCounts; raw metadata; timestamps) and what is deliberately excluded (icon base64). That is genuine added meaning an agent could not infer from 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?

The opening sentence gives a specific verb and resource plus scope: "Returns all grounds the authenticated user can access, with latest activity timestamp." It is clearly a listing tool and is further distinguished from siblings by pointing at slug discovery and naming list_wiki as the companion reader.

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 states explicitly when to reach for this tool first ("Use this first to discover slugs for other tools") and routes follow-up actions to named siblings (list_wiki, create_bug, update_bug). It also gives when-not guidance indirectly by spelling out that a viewer role gets 403 on every write tool, so an agent knows listing is the safe entry point and writes are gated.

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