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

Annotations only say readOnly=false, destructive=false, openWorld=true; the description adds substantial behavior beyond that: attack runs the entire fight autonomously and answers within 40 s, move waits until arrival, wait wakes early, and tactics persist server-side every tick even between calls. It also discloses the secret-handling requirement for sessionId, the caption rate limit (once per 3 s), and the irreversibility of the one-way ferry with an explicit instruction to ask the human first.

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?

Given 16 top-level parameters and nested objects, the length is largely justified, and the most critical facts (sessionId on every call, one key per call) are front-loaded. There is some redundancy — "A walk_to waits until you arrive" appears in the action bullet and again in the move bullet — but no bullet is 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?

With no output schema, the description still tells the agent what comes back ("Every result says what happened and shows the fresh world, so one call per decision is enough") and how failures are reported. Combined with sibling routing and the session bootstrap instruction, an agent has everything needed to invoke this complex dispatcher correctly.

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 the baseline is 3, but the description goes further by telling the agent where valid values come from — THREATS for fight viability, SPELLS READY for castable spells, the GATHER line for nodes, TELLS for search targets, and golemreach_look about:"recipes"/"guild" for craft and guild ids. It also clarifies defaults that matter operationally, such as loot being the implicit mode when no item is given and keepDistance 4-6 for ranged characters.

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 tool is a polymorphic action dispatcher, and the description makes that concrete by enumerating every accepted key (action, move, attack, cast, use, talk, trade, craft, travel, guild, wait, tactics, watch, invite_administrator). It also explicitly separates itself from the read sibling: "To read, use golemreach_look." The only weakness is the generic opening line "Do something in the game," which alone would not identify the tool.

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?

It states the core calling convention up front ("Pass ONE of the keys below per call"), routes reads to golemreach_look, and gives conditional exclusions such as "move:{unstuck:true} only when boxed in inside a temple" and "Check THREATS first: if you would last under about 15 s, do not fight." It even maps rejection codes to next actions ("cooldown" → wait, "protection_zone" → step off the P tiles), which is unusually actionable guidance.

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