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

Annotations only supply readOnlyHint=false, so the description carries the disclosure burden and does well: it states the client validates AP, path, ammo and zones, and warns that take_on/take_off mid-battle have a real consequence (medkits and barriers only apply from hand). It never says whether an invalid action rejects the whole batch or whether the plan persists until submit, so the mutation semantics remain partly opaque in a way annotations cannot cover.

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?

Purpose is front-loaded in the first clause and the remaining text is a tightly packed semicolon list where each entry earns its place with a required-parameter signature plus a qualifier. It is dense to the point of being hard to scan and some parenthetical asides compete with the operational notes, but there is no filler.

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 nested array of 14 action variants with no output schema and no field descriptions in the schema, the description supplies nearly everything an agent needs to construct a plan, including the in-hand and adjacent-cell constraints. The gaps are the omitted "getall" action and the absence of any statement about validation failure behavior or plan lifecycle.

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?

There is only one top-level parameter, but it is a 14-variant discriminated array whose fields are undocumented in the schema, so the type→fields mapping in the description (move{bx,by}, shoot{target,fire_type,zone,weapon_id?}, take_on{item_id,slot}) is genuinely additive. It is nonetheless incomplete: the enum contains "getall", which the description never mentions, and bx/by units or coordinate ranges are left unexplained.

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?

A concrete verb+resource ("add actions to the turn plan") followed by an enumeration of every action variant, so an agent immediately knows this builds a battle plan rather than executing one. It does not explicitly distinguish itself from siblings like game_battle_submit / game_battle_clear, which the plan/review/submit workflow implies but never states.

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?

Per-action notes encode usage conditions (e.g. heal requires the item to be in hand, pickup targets an adjacent cell, away only after the sector is cleared), which is useful when-to-use guidance at the action level. However, there is no statement of when to call this versus game_battle or game_battle_submit, nor whether the plan must be finalized by another tool.

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