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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile needs no restating. The description adds two pieces of real behavioral context beyond that: results are ordered most recent first, and totals are aggregated over all matching results rather than the limited page. It stops short of describing pagination limits or empty-result behavior.

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?

Two short sentences, front-loaded with the resource and shape of the result, then the ordering and aggregation caveat. No redundant restatement of the title or parameter list, though the trailing fragment about totals is slightly dangling without saying where totals appear.

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?

An output schema exists, so return-value details are not the description's burden, and the schema fully documents all five parameters. What remains missing is minor but real: no guidance on the relationship to get_event_results or on behavior for an unknown dancer ID, which matters for an ID-keyed lookup.

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 description coverage is 100%, with every parameter documented including role values, division examples, and limit bounds, so the baseline is 3. The description only refers to 'filters' generically and adds no syntax or semantics the schema does not already carry.

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 gives a specific verb and resource ('List a dancer's WSDC Jack & Jill placements') and enumerates the returned fields (event, date, division, role, placement, points), so the agent knows exactly what comes back. It does not name any sibling such as get_event_results or get_dancer_profile to distinguish the inverse/predecessor view, so differentiation is only implicit.

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?

Usage is implied rather than stated: the agent can infer this is the per-dancer results lookup, and the mention of filters hints that role/year/division narrow results. There is no explicit when-to-use versus get_event_results or search_dancers, and no note on what happens when the wsdc_id is unknown or the filters match nothing.

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