validate_selection

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It usefully explains that bench order is semantically meaningful and that output is authoritative, which are important implementation details. However, it is silent on whether this is side-effect-free, what permissions are needed, how errors are surfaced, or what validation categories are returned, leaving some behavioral risk opaque.

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 description is only three sentences: a clear opening goal, a critical bench-order constraint, and a decisive authority note. Every sentence carries operational value, and the most important information is front-loaded. No fluff or duplicated schema content.

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?

The description is enough to understand the basic validation task and the key bench-order semantics, and an output schema is present to document return values. But without annotations or explanations of the referenced regulation sections, and with only partial parameter coverage, it is adequate rather than comprehensive. An agent might still hesitate on when to prefer this over simulate_autosubs or how broad its authority is.

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 0%, so the description must compensate for the semantics of the parameters. It adds meaning mainly for 'bench' by explaining order importance, and it indirectly references the starters/formation count. It gives no semantic guidance for 'captain' or 'coach_id', which remain underspecified beyond their schema names and types.

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 says 'Check a team sheet against §6.13, §6.17 and §10.3(l)', which gives a specific verb and resource for the tool. It clearly distinguishes validation from sibling tools like search_squad or simulate_autosubs, though it does not explicitly contrast with them. The legal-section references are cryptic, but the core action is not ambiguous.

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?

The statement 'Bench order matters — the first substitute listed is the first to come on' provides concrete guidance for how the tool interprets its input, and 'This is authoritative: trust it over your own count' tells the agent when to rely on the result. It does not name alternative tools explicitly, but it gives clear context that prevents misuse of the bench ordering and formation-count semantics.

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