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

Annotations already declare readOnly/idempotent/non-destructive, and the description usefully confirms the consequence: 'Free draft only; no saving or publishing.' It adds genuinely behavioral context beyond the schema — full draws run n*(n-1)/2 matches and may need multiple court waves, rotating doubles will not guarantee everyone meets everyone, and it must surface fixtures in full round-by-round rather than summarizing. It stops short of describing return shape or failure modes, so not 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?

The critical mandate is front-loaded, but the body repeats the same rule several times ('Never infer sport or format', 'Establish sport first', 'Before calling, establish singles vs fixed teams', 'Never infer fixed teams from an individual player count'). It reads as a policy document rather than a tool description, and the actual 'what this does' clause lands mid-paragraph after the preamble. Tightening the duplicated clarification guidance would materially help.

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 10-parameter, 6-required generator with no output schema, it covers the decisions an agent must resolve first (sport, format, players-vs-teams, full vs limited rounds, session time), the downstream consequences (court waves, total match count, over-time fallback), and the sibling routing. Nothing needed to call this correctly is left unstated.

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 90% so the baseline is 3, but the description genuinely adds semantics: 'count' means players for singles/rotating and complete teams for fixed doubles (never silently divided); 'mode' rotating_doubles requires a numeric round count while 'rounds: auto' is only valid for full singles/fixed-team draws; 'durationMinutes' should be asked, not assumed 20. This disambiguates the two knobs (count and rounds) that the schema alone leaves risky.

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 combination and enumerates the three fixture shapes it produces for pickleball (singles, fixed-team, rotating doubles). It also explicitly routes away from siblings: rotating partners go here 'not generate_americano', and 'pickleball round robin or knockout' distinguishes it from generate_bracket. An agent can tell which generator it is without opening a schema.

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?

Explicit when-to-use, when-not-to-use, and alternatives: missing sport/format → ask or call get_supported_tournament_options; padel Americano → generate_americano; pickleball knockout → generate_bracket. It even gives a worked counter-example ('Make a tournament for 20 players on four courts' requires clarification, not an Americano) and forbids inferring from player/court counts or defaults.

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