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

With no annotations, the description carries the full burden and discloses a lot: the output is an unsigned transaction ('prepare (unsigned)'), enter requires no licence and 'no payment', applicants are 'equal' with odds fixed at apply time, and void means 'nobody loses anything'. It stops short of describing the sign-and-submit flow after preparation, which is the one behavioral gap for a prepare_* tool.

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 content is front-loaded with the action names and nearly every clause carries information, but the whole thing is one run-on sentence held together by semicolons and nested parentheses. Splitting the per-action clauses into separate lines would make the same content substantially easier to scan without adding length.

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 9-parameter, six-action lifecycle tool with no annotations and no output schema, the description covers the full state machine from applying through lottery, resolution, void, and claim. What remains unstated is the shape of the prepared payload and how it relates to get_air_runs for discovering run state.

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 100%, so per-parameter documentation is already handled, and the description largely restates it. It does add real semantics the schema lacks — members must be ordered 'you first, then a Hacker role 2 and/or Inside Agent role 5, each of whom called approve_leader for you' and minOddsBps is an odds floor — but this mostly duplicates the roles/members schema descriptions, so the gain is modest.

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 states a specific verb and resource — 'prepare (unsigned) one player step of an Air Run' — and the six enumerated actions define the scope far better than the bare name would. It does not, however, distinguish itself from overlapping siblings such as prepare_approve_leader or claim_seat, so an agent may hesitate between this tool's approve_leader/claim actions and those standalone tools.

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?

Each action carries an explicit precondition: enter only 'during its application window', advance only 'after the window', resolve 'after the flight's own drand round', void only when stalled 'for 6 hours', and 'call it again once the seat round is out' for advance. The approve_leader action is described by its purpose and required inputs, so an agent knows which action to pick for a given state.

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