Golemreach

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

With no annotations provided, the description carries the full burden and delivers: it discloses that the call runs an entire fight rather than a single swing, when it returns (monster dead, fled, or time budget), the retreat behavior of keepDistance, the default looting, and the meaning of common failure strings. It even warns about consequence-bearing behavior (paladins/sorcerers walked into melee if keepDistance is omitted).

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 internally structured with scannable section labels (BEFORE YOU COMMIT, RANGED CHARACTERS, RETURNS, COMMON FAILURES), and each section earns its place for an 8-parameter tool with no annotations. Minor redundancy: the sessionId security warning is duplicated almost verbatim in the schema parameter description.

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 zero annotations and no output schema, the description remains complete: it explains return values ('what happened, experience gained, damage taken, what you looted'), covers the no-required-parameters case (attack nearest hostile), enumerates common failure modes with remediation, and provides fight-safety heuristics. Nothing an agent needs to call this correctly is missing.

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, and the description adds complementary tactical meaning beyond the schema: the threat-DPS survival formula, the rationale that keepDistance is 'the whole reason a bow is worth carrying,' and the pass-neither target-selection fallback. It does not restate the per-parameter defaults, but it frames how parameters interact strategically.

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?

States a concrete verb and resource ('Kill something... fight the nearest hostile thing') and fully differentiates itself from siblings by specifying the whole-fight automation: it closes to range, attacks on the weapon's cadence, heals, flees, and loots. The distinct multi-turn combat behavior described is clearly not what golemreach_cast, golemreach_move, or golemreach_use do.

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?

Gives explicit preconditions ('If you have no sessionId yet, call golemreach_connect once'), a refusal threshold (do not fight under ~15 seconds of survival), and routing advice for failures (look again on not_found, ask an NPC where to hunt). It does not explicitly name sibling alternatives for the core combat decision (cast vs attack), leaving some differentiation implicit.

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?

The description discloses critical behavioral traits beyond annotations: sessionId grants control and must be kept private, spells are pre-filtered by the server, directional spells are aimed from the caster, summons have limits (2 pets, 10 minutes, no protection zones), and common failure modes with exact error strings. This is rich behavioral context that annotations do not provide.

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: sessionId handling, spell identification, pre-filtering, targeting rules, directional mechanics, summon limits, return values, and failure modes. It is front-loaded with the most critical operational requirement (sessionId) and uses clear section headers. Slightly verbose but justified by the tool's complexity.

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 the tool's complexity (7 parameters, no annotations, no output schema), the description is remarkably complete. It covers prerequisites, targeting rules, failure modes, return values, and edge cases like diagonal waves and invalid self-targeting. An agent has everything needed 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?

Schema coverage is 100%, so the schema already documents all parameters. The description adds meaning by explaining when each parameter is needed (targetId for attack spells, direction for waves/beams, x/y for tile-targeted spells, sessionId for every call) and by clarifying that healing/support spells usually need nothing. This goes beyond the schema's basic descriptions.

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 the tool casts one spell, identified by id or incantation, and distinguishes it from siblings like golemreach_attack and golemreach_use. It specifies the resource (spells) and the action (cast), making the purpose unambiguous.

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 provides explicit when-to-use guidance: check the SPELLS READY line first, use golemreach_connect if no sessionId, and use golemreach_use for potions instead of casting. It also names alternatives and conditions, such as knights drinking potions via golemreach_use, and explains when targetId vs direction vs coordinates are needed.

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 discloses side effects (account registration, character creation), persistence semantics (token and character are remembered between runs), security implications (sessionId grants character control), and common failure modes with remedies.

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 fairly long but nearly every sentence is load-bearing, and it is well-structured with clear sections for returns and common failures. The most critical rule about sessionId is front-loaded. Minor redundancy between the description and the schema's sessionId text keeps it from a 5.

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 and no annotations, yet the description covers the mandatory first-call behavior, resumption semantics, return contents, parameter hints, and failure recovery. An agent has enough context to call this tool correctly and know what to expect.

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 covers 100% of parameters with helpful descriptions, so the baseline is 3. The description adds meaningful operational context for fresh, characterName uniqueness/collisions, token persistence, and the need to pass sessionId with every call, going slightly 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 clearly states the tool's exact purpose: 'Join the game', 'registers an account, creates a character and walks it into the world in one step'. It also establishes itself as the mandatory entry point: 'This is always your first call', which separates it from the gameplay-action sibling 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 usage conditions: call it first, call it again only after disconnection, and pass fresh:true only when a brand new account is wanted. It also includes a concrete recovery path for the common server-unreachable failure, telling the agent to start the server or pass serverUrl.

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?

Since there are no annotations, the description carries the behavioral burden. It meaningfully discloses that sessionId grants character control, that abandoning is free, and that champion dangerZones show fixed strike tiles and dodge timing. It stops short of describing exact effects of every operation, but it is substantially transparent.

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 not overly long, but the first paragraph repeats the sessionId guidance that already appears in the sessionId parameter description. The second paragraph is dense and useful, so the duplication keeps this at average rather than high.

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?

This tool has five parameters, an enum-heavy operation list, and no output schema, so the description needs to fill many gaps. It does not explain where expeditionId comes from, what response each operation returns, or how the 'title' operation works. The overall game loop is described, but call-critical details are missing.

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 only 20%, so the description must compensate. It explains reward via 'supplies or extra gold' and maps many operation values into the workflow. However, it never explains the 'title' parameter or when 'expeditionId' is required, leaving two of five parameters underspecified.

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 title and description clearly identify the resource: Lantern Guild expeditions and trophies. It names distinct operations like board, accept, survey, challenge, claim, abandon, and title, which separates it from sibling tools such as golemreach_attack or golemreach_trade.

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 provides a start-to-finish workflow: get a sessionId via golemreach_connect, collect the starter kit, pick an expedition, then survey, challenge, claim, or abandon. It does not explicitly say when not to use this tool or point to alternatives for non-guild actions, but the context is clear enough for an agent to follow.

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. It discloses the return shape, that capacity is a real constraint that silently stops further looting, that observations will start warning about it, that the tool is free and has no cooldown, and that the sessionId grants control and must be kept private. This is substantial behavioral context.

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 and front-loaded: session requirement first, then purpose, then use cases, then returns. It is somewhat verbose and repeats the sessionId security warning already present in the schema, but each section contributes useful context and the organization is easy to follow.

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 appropriately compensates by explicitly describing the return contents: equipped items by slot, backpack contents stacked by kind, gold, and used versus maximum capacity. It also explains why the capacity information matters behaviorally. For a simple one-parameter tool, this is complete.

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 single parameter has 100% schema description coverage, including the security warning about the sessionId. The description repeats this guidance but adds no new parameter-level meaning beyond the schema. Baseline 3 is appropriate because the schema already does the heavy lifting.

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 uses a specific verb and resource: 'List your equipment, your backpack, your gold and your carry capacity.' It clearly distinguishes this from siblings like golemreach_attack, golemreach_move, golemreach_trade, and golemreach_use, especially by noting that the square-bracket ids returned here are what use/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 concrete trigger conditions: use it before a shopping trip, when a loot attempt reports you are full, or when you need an exact item id for golemreach_use or golemreach_trade. It also tells the agent to call golemreach_connect first when no sessionId exists, which makes the routing between siblings explicit.

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 behavioral burden. It fully discloses the non-destructive nature of the operation, states that the code is single-use and expires, warns that sessionId grants control of the character, and explains what happens if the code lapses. This is exemplary transparency for a sensitive account-transfer operation.

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 strictly necessary and repeats the sessionId instruction found in the parameter schema, but it is still well-organized and front-loads the most critical security warning. The structure clearly moves from prerequisite, to operation, to intended usage, to return value, with 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 single-parameter tool with no output schema and no annotations, the description is complete. It explains the return value, the redemption flow, expiration behavior, prerequisites, and the exact scenario in which the tool should be used. An agent has everything needed to select and 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?

Schema description coverage is 100%, so the schema already fully documents the sessionId parameter. The description repeats the same warning about sessionId rather than adding new parameter semantics. It slightly reinforces that sessionId is effectively required even though the schema lists no required parameters, but this adds minimal value 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 clearly states the tool's function: issuing a one-time code that grants a human administrator access to the account. It explicitly distinguishes this from game-state mutations by saying every character, level, item, and quest flag stays intact. This is a specific verb and resource, and it is clearly different from the sibling game-action 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 provides explicit when-to-use guidance: 'Use this when you want a person to be able to take over from here.' It also states the prerequisite clearly: call golemreach_connect first if no sessionId exists, and it can be called 'any time after golemreach_connect, even before entering the world.' No alternative tool is needed because this is a unique admin-handoff operation.

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 goes well beyond a simple action: it discloses the return format in detail, the map legend, that looking costs no game time, the meaning of HUNGRY, and the common failure mode where creature ids die or leave sight. It also warns that sessionId grants control of the 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 long but every section earns its place: session handling, mode selection, cost, map legend, status-line warning, and a named failure mode. It is front-loaded with the most critical operational warning and uses headings and concrete examples to keep the length navigable.

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 fully compensates by documenting return contents, legend symbols, failure behavior, and the absence of cooldown. All six parameters are either covered in the description or already fully described in the input schema, so an agent has what it needs to 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?

Schema coverage is 100%, so the baseline is 3, but the description adds useful semantics: creature ids are per-instance and don't survive kills, coordinates can be derived from map row labels and x-range header, and target is mutually exclusive with x/y/z. It does not add much to the detail parameter because the schema already explains it.

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 action ('See the world') and clearly distinguishes the two modes: no arguments returns the full situation (map, creatures, items, events, cooldowns), while a target inspects a creature or tile. This separates it from siblings like golemreach_attack or golemreach_move and tells an agent exactly what to 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?

It gives explicit when-to-use context: 'Looking is FREE — it has no cooldown and costs no game time. Look before every decision you are unsure about.' It also tells agents to call golemreach_connect first if they lack a sessionId. It does not explicitly compare against alternatives such as golemreach_where, but the guidance is clear enough for selection.

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 an excellent job. It discloses that the tool blocks until arrival, paths server-side, opens doors and follows stairs, returns final position and world view, treats diagonal steps as three cardinal steps, and may stop mid-journey on floor changes with a precise recovery instruction.

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: session requirement, two usage modes, return values, and common failures. Headings and numbered modes make it easy for an agent to parse, and the most critical requirement (sessionId) is front-loaded.

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 the tool's complexity, the absence of an output schema, and the absence of annotations, the description is remarkably complete. It covers how to invoke both modes, what to expect on success, what common errors mean, and how to recover from interrupted journeys.

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 beyond the schema: x/y/z must be given together for travel, direction is for single-step movement, diagonal cost differs from cardinal, stopDistance is for standing adjacent, and avoidCreatures false is for blocked corridors. The sessionId guidance is also reinforced here.

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 the tool moves the character and distinguishes two modes: TRAVEL by coordinates and STEP by direction. It names the resource (character), gives concrete behavior, and is easily distinguishable from sibling tools like golemreach_attack or 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: TRAVEL for anything further than a couple of tiles, STEP only for fine positioning. It also directs the agent to golemreach_connect when no sessionId exists and to golemreach_where for destinations, and explains how to handle no_path and floor-change recovery.

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 succeeds. It discloses key behavioral details: asking about task is accepting it, kills count automatically, hand-in must be with the same NPC, out_of_range means you are beyond 3 tiles, leads are name/direction only, and the response includes stock on trade topics.

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 well-organized, with each paragraph covering a distinct concern: sessionId handling, core behavior, key topics, return values, and failure recovery. The sessionId warning is front-loaded because it is required for every call, 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?

Given the tool's complexity and the absence of an output schema, the description is remarkably complete. It covers inputs, ID resolution, behavior, return values, common failure modes, range requirements, and the exact mechanics of task acceptance and hand-in. An agent has enough information to use this tool correctly without further investigation.

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 covers all three parameters, giving a baseline of 3. The description goes beyond the schema by explaining where npcId values come from ('n3' vs 'general_store'), showing that text is free-form English, and adding example phrasings. This is substantial supplemental meaning but not exhaustive for every parameter.

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 names a specific verb and resource: 'Say something to a non-player character,' and clearly explains the broader purpose of talking, such as discovering locations and getting work. It also distinguishes itself from related tools by pointing to golemreach_trade for buying and golemreach_where for progress checks.

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?

Usage guidance is explicit and actionable: call golemreach_connect first if you lack a sessionId, use golemreach_move when out_of_range, use golemreach_trade for buying, and use golemreach_where to check progress. It also states that talking is the only way to find locations and get work, making the decision to use this tool 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 and delivers: it discloses four named failure modes with plain-language meanings (not_for_sale, too_expensive, out_of_range, not_enough_capacity), the 3-tile positional constraint, the return value ('what changed hands and for how much'), and the security implication of sessionId. This goes far beyond what any structured field provides.

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 well-organized — the critical sessionId warning is front-loaded, and the RETURNS and COMMON FAILURES sections are labeled for easy scanning. It loses a point because the sessionId paragraph duplicates the schema's sessionId description verbatim rather than adding new information.

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 5-parameter tool with no annotations and no output schema, this description is unusually complete: prerequisites, discovery workflow, return summary, and all common failure modes are covered. The RETURNS line compensates for the missing output schema by telling the agent exactly what to expect back.

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, and the description adds genuine value on top: it explains how to obtain valid values for npcId and itemId (via golemreach_where and golemreach_talk 'trade'), and the failure messages tie directly to parameter misuse. Count semantics are left entirely to the schema, which is acceptable but not enhanced.

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 title and description state a specific action and resource: 'Buy from or sell to a merchant' and 'Exchange gold with an NPC merchant.' Trading is unambiguously distinct from the sibling set (attack, cast, move, talk), and the description even clarifies the strategic purpose (selling loot to afford potions and gear).

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 prerequisites ('Stand within 3 tiles of the merchant first') and routes to the exact sibling tools for each discovery step: golemreach_where for shop coordinates and golemreach_talk with 'trade' to learn item ids and prices. It also frames when the tool matters (walking back to town to sell loot), leaving no inference needed.

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 sessionId grants character control, that loot mode scans a 3x3 area, that corpses rot and cannot be carried, and it enumerates common failure modes with their remediation. It also clarifies that eating restores no health but prevents all regeneration.

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 well-structured with mode definitions, return info, common failures, and corpse notes. It is front-loaded with the critical sessionId security warning. A small deduction for repeating the sessionId instruction verbatim in the input schema and for some slightly verbose explanatory passages, though most sentences convey unique operational knowledge.

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?

A six-parameter tool with no output schema is fully covered: it explains return values, failure strings, parameter defaults, edge cases around corpses and capacity, and provides examples of item ids. The agent has enough information to invoke this tool correctly in combat, looting, eating, and inventory management contexts.

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, but the description adds substantial semantic value: item id examples, the default behavior of each mode, how equipment slots are inferred, the intent of minValue, and the interplay between item and mode. This goes meaningfully beyond the bare schema descriptions.

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 verb-resource scope: 'Everything you do with objects,' and enumerates five concrete modes (loot, use, equip, unequip, drop). It clearly distinguishes itself from siblings like golemreach_attack, golemreach_cast, and golemreach_move by defining object interaction as its domain.

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?

Provides explicit when-to-use guidance for every mode, including default mode selection based on whether an item is supplied, and calls out the prerequisite of golemreach_connect. It also gives contextual decision rules such as how knights heal, that eating is mandatory for regeneration, and that loot is collected with the "loot" mode because corpses are often not on the current tile.

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 that waiting is useless while hungry or on a protection tile, explains the server's cooldown model, warns that over-20 calls-per-second get rejected, and states that the return value is the world after the wait including everything that happened.

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 sentence earns its place: it front-loads the critical sessionId requirement, then moves from general purpose to specific mechanics to return behavior. Bold warnings and bulleted blockers make the density scannable without losing precision.

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 optional parameters, no annotations, and no output schema, the description is fully self-sufficient. It covers authentication, when to wait versus act, conditions that invalidate waiting, server behavior, and the shape of the return value.

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 adds practical meaning beyond the schema. It clarifies that untilHealthPercent-style regeneration depends on being fed and not standing on a P tile, and it distinguishes between waiting for a cooldown versus waiting for regeneration, which helps the agent choose between seconds and untilHealthPercent.

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 is explicit about the action: "Stand still for a while and then report what changed," and names concrete purposes: letting a cooldown lapse, regenerating health/mana, observing monster movement. It distinguishes the tool from siblings by naming golemreach_connect and golemreach_use as the correct alternatives for missing sessionId and eating, respectively.

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 explicitly states when to use wait: "Use it to let a cooldown lapse, to regenerate health and mana between fights, or to see whether a monster comes to you." It also says it is "the correct response to a 'cooldown' rejection," advises "Eat first (golemreach_use with item 'bread')," and tells the agent to call golemreach_connect if no sessionId exists.

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 disclosure burden, and it does so thoroughly. It explains that results are per-character, that an empty list is correct for a new character, that leads deliberately lack coordinates, that hunting grounds show personal kills rather than spawn lists, and that bestiary detail grows at 5 and 25 kills. It also discloses the security implication of sessionId and that the tool requires an active 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 long but well-structured with clear paragraphs, imperative guidance, and a return-category summary. Some redundancy exists, particularly repeating the sessionId instructions that already appear in the schema, but the added gameplay context is valuable enough to justify most of the 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?

Given the lack of annotations and output schema, the description is remarkably complete. It covers the tool's purpose, return categories, empty-result semantics, follow-up actions using sibling tools, when to call it, and authentication requirements. An agent has everything needed to call this tool correctly and interpret its results.

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 documents all three parameters with 100% coverage, including the sessionId pattern and caveats. The description reinforces the sessionId security guidance but adds no new meaning for the level or limit parameters, so the baseline score of 3 is appropriate.

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 exactly what the tool does: it returns the character's own knowledge — hunting grounds, leads, quests, bestiary, places visited, and towns. It explicitly distinguishes itself from a world directory and from sibling tools like golemreach_talk and golemreach_move by describing how knowledge is acquired.

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: call it early, after every conversation, and whenever there is nothing to fight. It also tells the agent when NOT to use it: if the list is empty, call golemreach_talk to ask an NPC for a lead instead of calling this tool again.

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