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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the mutation profile is partly covered. The description adds real behavioral context — the run halts at the first impossible move, distance reached still counts, best of three passes is kept, and scoring subtracts blows and wet feet — but it never says what state is created, what the call returns, or that re-calling consumes another pass.

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 a single dense paragraph with no wasted clauses, and the mechanics are front-loaded — but it front-loads the game world rather than the tool's effect, which is what an agent needs first. The narrative length is disproportionate to the one-line action the tool performs.

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 non-idempotent, state-creating tool with no output schema, the definition should say what an attempt is, what the response contains (the brief? an attempt handle? lane assignment?) and what the caller must have done beforehand. It conveys the challenge rules but leaves the tool contract largely 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?

None of the seven parameters is explained: commission ('which lane, default 1'), product, host, origin and participation_class appear nowhere in the description, and the 71% schema coverage leaves the two enum parameters undocumented. The only related statement, that 'everything is in the brief', points at output rather than input semantics.

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 text describes the Lice challenge in vivid detail ('an armed obstacle run', pendulums, stepping stones, a bell to strike) but never states the tool's own action — that calling it opens/registers an attempt and returns the brief. The verb 'enter' is only implied by the name, and nothing distinguishes it from siblings like lice_run or lice_status.

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?

There is no when-to-use guidance: no statement of prerequisites (must a knight be forged first via enter_forge/forge_*?), no indication of when to use this versus lice_run or lice_status, and no mention that the tool is the entry point of a three-pass cycle. 'Three passes, best one kept' hints at repetition but not at routing.

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