Golemreach

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

No annotations are present, so the description carries full responsibility for behavioral disclosure. It does this thoroughly: it explains the whole fight is automated, the healing/fleeing thresholds, that it loots by default, that it returns after death/flee/timeout, and that monster pathing prevents luring. This prepares the agent for side effects and reasonable expectations.

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 long, but every section earns its place: the targeting modes, the fight-loop explanation, the threat check, ranged behavior, return values, and common failures. It is organized into labeled paragraphs and front-loaded with the most essential targeting logic. Slightly rambling in places but appropriately structured for a high-stakes combat action.

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 complex tool with 7 optional parameters, no output schema, and no annotations, this description is unusually complete. It covers targeting, overrides, risk assessment, failure modes, pathing limitations, and return values. The only small gap is not explicitly describing what happens to the loot parameter behavior when set to false, though the schema already handles that.

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 parameters are already well documented. The description adds extra value by explaining the core choice between targetId and monster, the meaning and consequence of keepDistance for ranged users, and the survivability calculation based on threat. It doesn't repeat parameter names, but it supplies context that the schema alone lacks.

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 leads with a concrete verb and resource: 'Kill something' by creature id, monster name, or nearest hostile. It clearly distinguishes this from siblings like golemreach_use, golemreach_cast, and golemreach_talk by framing it as the whole-fight combat action. The scope is unambiguous and actionable.

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 description gives explicit when-to-use guidance and exclusions: when to pass targetId vs monster vs nothing, when keepDistance is needed for ranged characters, how to avoid protection_zone, and how to recover if not_found. It even tells the agent not to fight when threat suggests low survival, which is strong decision guidance.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses server-side pre-filtering, rejection behavior, per-spell and shared group cooldowns, common failure codes with their meanings, and what the tool returns. This goes well beyond what the schema reveals.

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 long but dense and every section earns its place: purpose, prerequisites, target requirements, return value, and failure modes. The use of labeled sections like RETURNS and COMMON FAILURES makes the information easy to scan, and no sentences are wasted.

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 five-parameter casting tool with no annotations and no output schema, the description is remarkably complete. It explains how to discover castable spells, where the full catalogue lives, how targets are chosen, what the response contains, and what errors to expect. An agent has enough context to invoke this tool 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?

The schema already describes all five parameters, so the baseline is 3, but the description adds meaningful context: spell can be supplied as id or incantation, attack spells need targetId or coordinates, and healing/support spells usually need nothing. It does not map every spell to a specific parameter combination, but it points to the catalogue for that detail.

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 states a specific action ('Cast one spell') and names the resource via 'spell id or incantation', with concrete examples like 'light_healing' and 'exura'. It clearly distinguishes spell casting from the sibling golemreach_use by noting that knights drink potions instead.

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 description gives explicit when-to-use guidance: check the SPELLS READY line in any look first, and only cast spells that appear there. It also names an alternative tool, golemreach_use, for knights who would otherwise try to cast healing spells, and explains when targeting parameters are required.

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

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

With no annotations supplied, the description carries the full behavioral burden and meets it: it covers account registration, character creation, world entry, idempotent resumption, token/character memory between runs, fresh:true override, return payload, and two common failure modes. There is no annotation contradiction.

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 front-loaded with the key directive, then uses labeled RETURNS and COMMON FAILURE sections so an agent can scan efficiently. Every section earns its place by addressing selection, resumption, expected output, or troubleshooting.

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 7-parameter setup tool with no output schema, the description is complete: it explains what the response contains, when a second call is appropriate, how to force a new account, and how to react to the most likely failures. The absence of an output schema is compensated by the explicit return description.

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 100%, so the baseline is 3. The description adds meaningful behavior beyond the schema: fresh:true means force a new account, characterName collisions are server-wide and require a different name, and serverUrl matters when the game server listens elsewhere. This lifts it above baseline, though the schema already handles individual parameter semantics well.

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?

Description opens with 'Join the game' and states it 'registers an account, creates a character and walks it into the world in one step, then returns your first look at the world.' This is a specific verb+resource that clearly distinguishes the connect/setup tool from the action-oriented siblings like golemreach_attack and golemreach_move.

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 explicitly says 'This is always your first call,' which tells the agent this must precede all siblings. It also gives the exact condition for calling again ('only if you were disconnected') and explains the resume/fresh:true choice. Common failure guidance further clarifies when to adjust serverUrl or characterName.

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

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

With no annotations, the description carries the full burden, and it delivers: it details the return contents, notes that capacity is enforced, warns that a full backpack silently stops looting, and mentions that observations will warn about capacity. It also clarifies there is no cooldown and the call is free.

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 well structured: a one-line purpose, concise use-case guidance, a RETURNS section, and a notable caveat about capacity. Every sentence adds information and there is no filler or repetition of the tool name.

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?

There is no output schema, so the description must explain return values, and it does: equipped items by slot, backpack contents stacked by kind, gold, and used versus maximum capacity. It also adds the important gameplay consequence of full capacity, making the definition complete for an agent deciding when and how to use this tool.

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?

The tool has zero parameters, so there is no parameter detail to add; the baseline is 4. The description instead clarifies what the returned IDs mean and how they connect to sibling tools, which is useful contextual semantics beyond an empty schema.

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 opens with a specific verb and resource: 'List your equipment, your backpack, your gold and your carry capacity.' It clearly states what the tool does and distinguishes it from sibling action tools by noting that the returned item IDs are what golemreach_use and golemreach_trade expect.

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 description gives explicit when-to-use guidance: before a shopping trip, when a loot attempt reports being full, and when needing exact item IDs for golemreach_use or golemreach_trade. It does not include when-not-to-use or alternative-tool comparisons, but for a zero-parameter inventory read the trigger conditions are clear and actionable.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure. It clearly states what changes and what does not, notes that the code is single-use and expires, explains that a fresh code can be requested, and specifies authentication requirements and the return value.

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 front-loaded with its core purpose, then compactly covers usage, lifecycle, and return value. Every sentence adds meaningful information, from the out-of-band redemption instructions to the expiry behavior, without redundant 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 tool with no parameters, no output schema, and no annotations, the description is remarkably complete. It covers invocation timing, prerequisites, side effects, redemption flow, code lifecycle, and return contents, so an agent has everything needed to select and call the tool 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?

The tool takes zero parameters, so there are no parameter semantics for the description to add. The description appropriately focuses instead on the output and usage behavior, matching the baseline for a zero-parameter tool.

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 opens with a specific verb and resource: issuing a one-time code a human can redeem to become the account's administrator. It also explicitly distinguishes the operation from game-state actions by clarifying that no character, level, item, or quest flag changes, which separates it from sibling gameplay 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?

The description gives explicit when-to-use guidance: when a person should be able to take over the account. It also states the prerequisite and timing (after golemreach_connect, even before entering the world) and explains how to hand off the code, leaving no ambiguity about when to invoke the tool.

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

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses that the action is free and costs no game time, details what the returned text contains, explains the ASCII map legend, highlights the status line meaning, and warns about creature ids not surviving a kill.

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 longer than average but highly structured and dense with useful information. Every section earns its place: overview, target usage, cost, return legend, status-line warning, and common failure. It is well front-loaded with the main no-arg behavior.

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?

Given five parameters and no output schema, the description is remarkably complete. It explains all calling modes, all relevant symbol meanings, the status line caveat, detail-level options, and a common failure case. An agent has everything needed to invoke the tool 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?

Although schema coverage is 100%, the description adds substantial meaning: target expects a creature id from the CREATURES list, coordinates are an alternative way to inspect tiles, detail levels are tied to concrete use cases, and the default is 'normal'. It also explains the failure mode for stale creature ids.

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 clearly states what the tool does: with no arguments it returns the full current situation, and with a target it inspects a creature or tile. It distinguishes this from generic actions by describing the exact no-arg vs target behaviors, making it easy to select among the listed siblings.

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 description gives strong contextual guidance: 'Look before every decision you are unsure about', explains the two calling modes, and notes that looking is free with no cooldown. It does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses that the tool waits until arrival, auto-paths across ticks and through doors/stairs, returns the final position and fresh world view, may stop on the far side of stairs when changing floors, and even explains the diagonal stepping cost. This goes far beyond what the schema alone conveys.

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 long but every section earns its place: two clearly labeled usage modes, a brief returns note, and a common-failures section. The structure front-loads the core decision (TRAVEL vs STEP) and then layers details, making it easy for an agent to scan and act.

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?

There is no output schema, so the description correctly explains what the tool returns: where the character ended up plus the fresh world view. It also covers edge cases like no_path, incremental multi-floor journeys, and repeated calls to finish a trip, making the tool fully self-contained for an agent.

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%, but the description adds meaning beyond the raw parameter docs: x/y/z must be given together to travel, direction chooses a single step, and stopDistance semantics are clarified. It also adds practical behavioral context such as avoidCreatures refusing monster-occupied tiles and the diagonal cardinal-step cost, which the schema descriptions do not fully express.

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 opens with the specific action 'Move your character' and immediately defines the two operating modes: TRAVEL (x/y/z coordinates) and STEP (direction). This makes the tool's purpose unambiguous and distinguishes it clearly from the movement-adjacent siblings like golemreach_wait and golemreach_where.

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 description gives explicit when-to-use guidance: use TRAVEL for anything further than a couple of tiles, use STEP only for fine positioning, and consult golemreach_where for known destinations. It also covers the lead-following case, multi-floor pathing, and common failure recovery, so an agent knows exactly when and how to invoke this tool relative to alternatives.

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

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

No annotations are provided, so the description carries the full burden, and it fully delivers. It discloses the accept-on-ask behavior, kill/fetch objective handling, progress counter details, three-tile out_of_range failure, accepted NPC id formats, and the return content (NPC speech plus stock when trading). This is far beyond a generic 'talk to NPC' description.

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 text is long but well-structured with bolded lead-ins, bullet lists, and dedicated RETURNS/COMMON FAILURE sections, so important information is findable. A few flavor phrases ('built for language rather than around it') and repeated examples add a bit of length, but the content is dense and mostly non-redundant.

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?

Given there is no output schema and no annotations, the description covers the full call cycle: how to get the target ID, what to say for each major intent, what happens in the game world, what the tool returns, and how to recover from the main error. An agent has enough context to invoke it successfully in the surrounding toolset.

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 schema already documents both parameters; the description adds practical value on top by giving example utterances, acceptable topic keywords, and two sources for npcId ('n3' or 'general_store'). It thereby explains how to obtain valid values, not just their 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 opens with a specific verb and resource: 'Say something to a non-player character.' It makes the tool's unique role explicit by stating talking is the only way to find locations and get work, and it distinguishes adjacent actions such as golemreach_trade and golemreach_where. This leaves no ambiguity about what the tool is for.

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 description gives explicit when-to-use guidance and names alternative tools: ask 'trade' to list stock then buy with golemreach_trade, ask 'task' to accept/complete quests, use golemreach_where to check progress, and use golemreach_move when 'out_of_range'. It also explains consequences like asking being acceptance and returning to the same NPC to hand in, so an agent can choose correctly and act on the result.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, and it delivers: it explains the 3-tile range requirement, describes the return value, and enumerates common failure messages with meanings. This is substantial context beyond the schema.

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 front-loaded with purpose, then prerequisites, return behavior, and failure modes. Every sentence contributes practical information and the structure is easy to scan.

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 tool with no output schema and no annotations, the description covers what happens, what can go wrong, and how to prepare. An agent has enough to call the tool correctly and interpret the result.

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 schema already documents all parameters including examples. The description adds contextual color around why item ids matter and how to discover them, but it doesn't materially extend the parameter-level meaning beyond the schema.

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 states a specific action — exchanging gold with an NPC merchant — and distinguishes buying/selling from sibling tools like attack, cast, talk, and look. The opening sentence immediately clarifies the resource (merchant) and the operation (buy or sell).

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 gives explicit prerequisites: stand within 3 tiles, use golemreach_where to find shops, and use golemreach_talk with "trade" to discover item ids and prices. This routes the agent to the right alternative tools and prevents common mistakes.

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

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

Annotations are absent, so the description carries the full burden, and it succeeds. It discloses the default mode behavior, that loot picks up from a 9-tile area, that corpses rot, that hunger blocks regeneration, and that some objects cannot be picked up. It also states what the tool returns and enumerates common failure strings.

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 long, but the length is justified by the five distinct modes and important mechanical caveats. It is well organized with labeled sections: modes, returns, common failures, and corpse notes, and the default behavior is front-loaded. Some details are verbose, but nothing feels like pure 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 annotations and no output schema, the description must teach an agent everything needed to invoke the tool safely and effectively. It covers mode semantics, param interpretation, failure resolution, item identity, and relevant world rules such as hunger and corpse looting. This is complete for a multi-mode object-interaction tool.

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?

The input schema already documents all parameters with 100% coverage, which gives a baseline of 3. The description adds valuable extra meaning: item ids are readable slugs, examples like 'health_potion' and 'short_sword', unequip uses slot names as item, and the default mode logic is explained beyond the schema.

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 states a clear scope: all object interactions, and enumerates five concrete modes (loot, use, equip, unequip, drop). This differentiates it from sibling tools like golemreach_attack, golemreach_move, and golemreach_talk by positioning it as the tool for everything done with objects.

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 description gives strong scenario guidance: looting corpses on adjacent tiles, drinking potions to heal as a knight, eating to avoid hunger, dropping items to free capacity, and how to handle common failures. It does not explicitly say 'when not to use this tool' versus specific siblings, but the mode list and examples make the intended use clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explains that waiting is not wasted time, that health/mana/soul do not regenerate while HUNGRY or in a protection zone, that food itself heals nothing, that the server rejects more than twenty calls per second, and that the wait returns 'the world after the wait, including everything that happened during it.' This is rich, honest behavioral context that an agent needs to make correct decisions.

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 longer than typical, but each sentence earns its place: the use cases, the cooldown rejection context, the two regeneration blockers, and the return value all carry decision-relevant information. It is slightly verbose in the 'twenty per second' server detail, but that specificity is useful for preventing the agent from spamming. Overall it is well-structured with clear emphasis markers.

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 zero-required-parameter waiting tool with no output schema, the description covers everything an agent needs: when to wait, when not to wait, what blocks regeneration, what parameters do, and what the return value contains. The sibling list shows that related actions like eating and moving are handled by other tools, and the description correctly routes the agent to golemreach_use with item 'bread' and to step off the 'P' tile before waiting.

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 100%, so the baseline is 3; the description adds value beyond the schema by explaining that seconds defaults to 3 and maxes at 60, and that untilHealthPercent rests until health and mana reach that percentage or time runs out. The description also frames both parameters in the context of the regeneration rules, helping the agent choose between a fixed wait and a conditional rest.

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 opens with a concrete verb phrase ('Stand still for a while and then report what changed') and lists explicit uses: letting a cooldown lapse, regenerating health and mana between fights, and observing whether a monster approaches. It clearly distinguishes the tool as the intended action for a cooldown rejection, which separates it from siblings like golemreach_attack or golemreach_move.

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 description gives unambiguous when-to-use guidance: it is 'the correct response to a cooldown rejection,' explains why retrying immediately is futile, and explicitly warns against rapid repeated calls. It also provides two concrete when-not-to-use conditions with exact remedies: being hungry (eat bread first) and standing on a 'P' protection tile (step outside). This is exemplary usage guidance.

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

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

With no annotations, the description carries the full behavioral burden and succeeds. It explains that an empty result is correct for new characters, that results change only through specific in-world actions, that leads deliberately have no coordinates, that hunting ground detail is not a spawn list, and that the tool is free but requires a connected character.

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 structured with clear sections and front-loaded identity, but it is long and somewhat discursive. Most sentences earn their place because they explain important game behavior, though a few ideas are repeated in different forms.

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?

Given only two optional parameters, no output schema, and the unusual game-world semantics, the description covers everything an agent needs: what results mean, why they can be empty, how to populate them, when to call the tool, and the prerequisite connect call. There is no critical missing context.

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?

The input schema already describes level and limit with 100% coverage, so the description does not need to repeat their meaning. It adds no additional context about how level or limit affect the response, which is fine but keeps this at the baseline.

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 states clearly that this tool returns the character's own knowledge: hunting grounds found, leads given, quests, bestiary, places walked past, and towns. It distinguishes itself from a world directory by saying no map exists and knowledge is only gained by walking in, killing, or being told.

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 gives explicit when-to-call guidance: early, after every conversation, and whenever there is nothing to fight. It also tells the agent exactly what to do instead when the list is empty—find an NPC via look and call golemreach_talk with 'where can I hunt?'—and warns that repeatedly calling this tool instead of talking will never change the result.

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