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

With no annotations, the description carries the full burden, but it does disclose one genuine behavioral trait: the attack is continuous (versus a single strike). It omits whether range/proximity is required, what happens if the target is invalid or out of range (attack_range exists as a sibling), and any cooldown or cost.

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?

A single short sentence with the action front-loaded and the parenthetical constraint appended efficiently. Nothing is wasted, though it is arguably too terse for the behavioral gaps it leaves open.

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 simple one-parameter game action with no output schema this is minimally viable, but it leaves out range/proximity requirements and the relationship to attack_range and stop_attack, which an agent would need to invoke it 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 0%, so the description must compensate. 'by ID' clarifies that target_id is an identifier of a being rather than, say, an item, which is useful, but it adds no format, range, or validity detail beyond that.

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 specific verb ('Attack'), the resource ('a being'), and the identifying mechanism ('by ID'), which maps cleanly onto target_id. It does not explicitly differentiate from the obvious sibling stop_attack, but the core action is 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?

There is no guidance on when to use this versus alternatives like stop_attack or attack_range, nor any prerequisites (e.g., target must be in range). Usage must be inferred entirely from the tool name.

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. It discloses that this overrides server auto-detected behavior, which is real context, but says nothing about persistence (per-session vs permanent), whether it can be reverted, or whether it affects only the next attack. For a state-changing configuration tool this is a meaningful gap.

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?

Two tight sentences, front-loaded with purpose and followed by value semantics. Every clause carries information; nothing is 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?

For a one-parameter tool this covers the essentials, but with no annotations and no output schema the description should say whether the override persists and how it interacts with server auto-detection (e.g., reset behavior). Adequate but visibly incomplete.

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 0% (bare integer with default 1), so the description must compensate — and it does, mapping 1 to melee and 2 to scythe/polearm, meaning far beyond the schema. It falls short of 5 because it never says what other values do or what happens if the field is omitted despite the default.

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 specific verb and resource ('Override weapon attack range') and adds the auto-detection context, so the agent knows this is a configuration override rather than an attack action. It does not explicitly distinguish itself from the sibling `attack` tool, which a 5 would require.

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 phrase 'normally auto-detected from server' implies this should only be used when auto-detection is wrong, which is useful implied usage. However, there is no explicit when-to-use/when-not-to-use statement and no named alternative (e.g., leave unset to keep server detection).

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. It does disclose one important state dependency (the buy list must already be open), but says nothing about currency/zeny deduction, whether the purchase is atomic, what happens on insufficient funds or invalid name_id, or the effect of count.

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?

Two short sentences with the prerequisite front-loaded after the action statement; nothing is wasted. It is terse rather than padded, though it errs toward under-specification.

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?

No annotations, no output schema, and 0% parameter coverage mean the description must do much more. The prerequisite is captured, but the item identifier semantics, quantity behavior, cost, and failure modes are all missing for what is an economically consequential mutation.

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 0% for both parameters, so the description must compensate and does not. It never mentions 'name_id' (an opaque integer identifier) or 'count', leaving the agent to guess what item identifier to pass and how quantity behaves.

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 specific verb+resource ('Buy items from shop'), so an agent knows what action is performed. However, it does not differentiate itself from the sibling tool 'shop_buy', which the description seemingly references as 'tmw_shop_buy', leaving ambiguity about whether this tool or that one performs the purchase.

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 a clear precondition: the buy list must be opened first via tmw_shop_buy. That is useful sequencing guidance, but there is no statement of when-not to use this tool or how it relates to the similar 'shop_buy'/'shop_sell' siblings beyond the single prerequisite.

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 does so well: it names the wire message and discloses the concrete failure mode (server keeps sd->state.storage_open set and silently drops walk/item-use packets). It does not describe a response or error behavior, which keeps it from a 5.

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?

Two tight sentences, zero filler, with the action front-loaded and the consequence immediately following. Every clause earns its place.

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-param, no-output-schema tool, the description covers the message identity, the required usage condition, and the consequence of omission. Nothing an agent needs to call it correctly appears to be 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?

The tool takes zero parameters, so the schema already fully describes the input surface. Baseline 4 applies; there is nothing for the description to add or omit.

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 specific verb (send) and the exact protocol resource (CMSG_CLOSE_STORAGE 0x00f7), so an agent knows precisely what the call does. It does not explicitly differentiate from the nearby npc_close sibling, which is the only gap keeping it from a 5.

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 a clear trigger: 'Required after clicking a storage NPC.' This tells the agent exactly when the call is mandatory. It stops short of naming alternatives (e.g., npc_close) or when not to use it, so not 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?

No annotations, so the description carries the full burden for a mutation tool. It never states whether dropping is reversible, what happens if the tile is occupied or the drop fails, or what permissions/preconditions apply. Only the amount=0 shortcut is disclosed.

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?

Two short sentences, zero padding, with the core action stated first and the amount convention immediately after. Nothing 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 mutation tool with no annotations, no output schema, and an undocumented required parameter, the description is too thin. It omits failure behavior, slot-index meaning, and any indication of irreversible state change.

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 0%, so any param meaning must come from the description. It usefully explains the amount default=0 as 'drop entire stack', but the required 'index' parameter is left completely undefined for an agent that must know it refers to an inventory slot.

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 specific verb (drop) and resource (item) plus the location (on the ground), which distinguishes it from pickup, use, and equip. However, it does not name a sibling it is not, so routing relies on the agent knowing the inventory vocabulary.

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?

No explicit when-to-use, when-not, or alternative tooling is given. The closest thing to guidance is the amount=0 convention, which is a parameter rule rather than usage context.

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 behavioral burden, and it discloses almost nothing beyond the action verb. It does not say whether the emote is broadcast publicly, whether there is a cooldown or spam limit, whether an invalid emote_id errors, or what side effects occur. Only the bare 'sending' signal is present.

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?

One short sentence with no filler, so it is structurally clean and front-loaded. The problem is under-specification rather than verbosity; the single sentence does not earn much because it conveys almost no information. Adequate form, thin substance.

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, no output schema, and 0% parameter documentation, everything an agent needs must come from the description, and it does not deliver. It omits valid emote_id values, visibility/broadcast scope, and any error behavior. For a one-parameter action tool this leaves meaningful gaps.

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 0% and the single required parameter emote_id has no title-side explanation beyond its name. The description adds nothing about valid id ranges, where to discover ids, or whether emote_id maps to a fixed table. With low coverage, the description is expected to compensate and completely fails to.

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 verb ('send') and a resource ('emote'), so an agent knows it fires off an emote animation/expression. However, it does not distinguish this from chat siblings such as say, whisper, or party_chat, nor clarify whether the emote is broadcast to nearby players or a target. Minimal but adequate purpose statement.

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?

There is no guidance on when to use this tool versus alternatives. An agent cannot tell from the description whether emote is for visual expressions only, whether it can be combined with say, or whether it requires being in a specific game state. No exclusions or prerequisites are given.

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 states that equipping happens but does not disclose side effects such as swapping/unequipping an existing item, requirements (level, class), error conditions, or whether the action is reversible.

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?

It is a single, front-loaded sentence with no filler. The brevity is not wasteful, though the same terseness contributes to the specification gaps noted elsewhere.

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 state-changing tool with no annotations, no output schema, and a 0%-documented parameter, the description is too thin. It does not explain parameter format, expected effects, or failure modes.

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 0%, and the only parameter has the bare title 'Index'. The description adds that the index refers to the inventory ('by inventory index'), which is meaningful, but it omits critical details like valid range, 0- vs 1-based indexing, and how to identify the target item.

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 ('Equip') and resource ('an item'), and scopes it to an inventory index, so an agent can understand the operation without opening the schema. It does not, however, differentiate itself from siblings like 'use' or 'drop', which also act on inventory items.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as 'use' or 'drop'. The usage is only implied by the verb 'Equip'.

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 disclosure burden, and it reveals almost nothing beyond the action itself: no indication of whether the change is instant, whether it interrupts walking/attacking, whether it persists, or what happens on invalid input. The only behavioral content is the direction value mapping, which is really parameter semantics.

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?

A single front-loaded sentence with zero filler that delivers purpose and the value encoding in one pass. Nothing could be removed without losing 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 one-parameter, no-annotation, no-output-schema action command, the description covers the two things an agent needs: what the tool does and how to encode the direction. The remaining gap is the ambiguity over undocumented odd values and failure behavior, which is minor for such a simple 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?

Schema coverage is 0% and the single parameter is a bare unnamed integer, so the description supplies the essential meaning by mapping values to compass directions (0=south, 2=west, 4=north, 6=east). It falls short of a 5 because it lists only even values with no range or validity statement, leaving an agent unsure whether 1, 3, 5, 7 (likely diagonals) or out-of-range values are legal.

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 specific verb and resource ("Change facing direction") that is immediately distinguishable from siblings like walk, sit, stand, or attack. It does not name or contrast with any sibling explicitly, which keeps it short of a 5, but an agent can tell what this tool does without opening the schema.

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?

There is no guidance on when to use this tool versus alternatives (e.g., turning before attacking, or whether walking changes facing), and no prerequisites such as needing to be in-game or restrictions while another action is in progress. Usage is only implied by the verb.

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 behavioral burden, and it does disclose the non-obvious trait that this is a deferred/automatic action rather than an immediate one. However it omits prerequisites (must be on a ferry), whether the exit can be cancelled, and what happens when bells exceeds the remaining stops.

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?

Two sentences, front-loaded with the core behavior and followed immediately by the clarifying example. No filler or redundancy.

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 simple one-parameter game action with no output schema, the description covers purpose, deferred behavior, and parameter meaning adequately. It would be stronger with a note about being on a ferry or whether the scheduled exit can be overridden.

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 0% and the single 'bells' parameter has only a type and default, so the description must compensate. It does so well by defining the semantics through concrete examples: bells=1 exits at the next stop, bells=2 skips one stop first.

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 ('auto-exit') on a specific resource ('the ferry'), so the agent knows exactly what domain action this performs. None of the sibling tools (walk, sit, stand, etc.) overlap, so no differentiation is needed, though it never explicitly frames itself against them.

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 is implied by the example ('bells=1 exits at next stop') rather than stated as when-to-use guidance. There are no alternative tools for ferry exiting to disambiguate against, and no mention of prerequisites such as needing to already be aboard a ferry.

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 behavioral burden, and it only discloses the stop mechanism. It does not say whether following is a persistent state, what happens if the target is offline or on another map, whether it interrupts other actions, or what success looks like.

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?

Two short sentences, no filler, and the primary action is front-loaded ahead of the stop instruction. Every clause earns its place.

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 one-parameter, no-annotation, no-output-schema tool it covers purpose, parameter meaning, and cancellation. However, because structured fields provide no behavioral context, it leaves the state/persistence semantics of following unstated, which is a meaningful gap for a state-changing game action.

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 0% and the schema only labels the field 'Target' with no description. The description compensates well: it explains the accepted identifier forms (name or ID) and the special empty-string value that halts following, which the schema does not convey.

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 specific verb and resource ('Follow a player') and clarifies the identifier forms ('by name or ID'). It is unambiguous on its own, but it does not distinguish itself from adjacent siblings like walk or attack, so it falls short of a 5.

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 one operational condition ('Pass empty string to stop'), which tells the agent how to cancel, but offers no guidance on when to follow versus walking, attacking, or other movement tools, and no prerequisites. Usage is implied rather than explained.

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. It does disclose genuine behavior beyond the schema: the hunt is continuous rather than one-shot, and an empty string terminates it. It does not say what happens on player death, when the monster is unreachable, or whether the loop ends on its own.

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?

Three short sentences, all load-bearing: purpose, multi-value format, and the stop sentinel. The core purpose is front-loaded 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 annotations and no output schema, the description covers invocation well but omits the operational context an agent needs to use it safely: relationship to 'attack'/'stop_attack', termination conditions, and any failure behavior.

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 0%, so the description must compensate, and it does: it defines the value as a monster name, specifies comma-separation for multiple types, and defines the empty-string sentinel for stopping. Only the exact accepted name format (case, exact spelling) is left undocumented.

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 ('hunt monster(s) by name') and adds a scope qualifier ('continuously'), which distinguishes it from a one-shot action. However, it never names the closely related siblings 'attack' and 'stop_attack', so an agent must infer the boundary itself.

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?

'Pass empty string to stop' gives real usage information about terminating the hunt, and 'continuously' implies the long-running nature of the tool. But there is no explicit when-to-use versus 'attack'/'stop_attack', and no statement of prerequisites such as being alive or in range.

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 behavioral burden and delivers almost none of it. It does not say whether the listing is paginated, whether it includes empty slots or slot indices needed by equip/drop, or whether it requires the player to be in a particular state. For a zero-param read tool the risk is low, but the disclosure is still minimal.

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?

A single short, front-loaded sentence with zero padding. It is efficient, though the brevity shades into under-specification rather than deliberate conciseness.

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 is the only place the return shape could be described, and it says nothing about what a listing contains (item names, slot indices, quantities). For a tool whose entire value is its output, this is a meaningful gap.

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 no parameters (0 params, empty schema), so there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% and the argument object is empty.

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 specific verb (List) and resource (inventory items), so the agent knows this is a read-only enumeration of the player's inventory. It does not, however, distinguish itself from inventory-adjacent siblings like equip, use, drop, or sell, which also operate on inventory contents.

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?

No guidance on when to call this versus alternatives such as `stat` (status info) or the various item-manipulation tools. The agent must infer that this is the discovery step before equip/use/drop, but the description never says so.

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. It usefully discloses the output format (ASCII minimap) and the read-only nature implied by 'Show', but says nothing about cost, permissions, or whether the view reflects live state. Adequate for a trivial display tool, but thin.

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?

A single front-loaded sentence with zero filler. Every word contributes to the meaning.

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 one-parameter read tool with no output schema this is minimally sufficient: the agent knows what it displays and where. The undocumented radius and the lack of any usage context keep it from being 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 'radius' parameter has 0% schema description coverage and is never mentioned in the description. The description's phrase 'around current position' gestures at scope but does not explain that radius controls the extent of the map, leaving the parameter's meaning to inference.

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 specific verb (Show), resource (ASCII minimap), and scope (around current position). No sibling tool clearly overlaps, so differentiation is adequate by default, though it does not explicitly distinguish itself from state-type tools that may also report location.

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 no when-to-use guidance, no prerequisites, and names no alternatives. An agent must infer that this is a read-only orientation aid rather than something to call before walking or attacking.

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 behavioral burden and discloses almost nothing: not whether the call blocks pending player selection, whether an out-of-range or invalid npc_id fails silently or errors, nor that further npc_* calls are typically required to progress the dialog.

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?

A single short sentence with the action front-loaded and no filler. It is efficient, though the terseness is partly the source of the specification gaps rather than deliberate economy.

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, no output schema, no enum, and 0% parameter documentation, the description leaves the agent unable to determine valid npc_id values or the follow-up calls. For a tool that anchors a multi-step dialog flow, this is a substantial gap.

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 0% for the single required parameter npc_id. The description only says 'an NPC' and adds no information about where the id comes from, whether it is a map-local entity id or a global template id, or what values are valid.

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 concrete action and outcome: clicking/targeting an NPC to open a dialog session. 'Start dialog' implicitly separates it from the continuation siblings (npc_next, npc_choose, npc_input_str), though it never names them or states that this is the entry point of the NPC interaction flow.

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?

There is no explicit when-to-use or when-not-to-use guidance. The sequence relationship to npc_next, npc_choose, npc_input_str, and npc_close is left entirely to inference, as is any prerequisite such as standing near the NPC or knowing its id.

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 behavioral burden, yet it discloses almost nothing: no behavior on an out-of-range index, no indication of what happens to the dialog afterward, and no error semantics. The single disclosed trait is the 1-based indexing convention.

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?

A single front-loaded sentence with the key qualifier in parentheses and no wasted words. Nothing could be trimmed without losing 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 tool embedded in a multi-step NPC dialog flow with no annotations and no output schema, the description should explain how the index relates to the menu and what happens on success or failure. As written, an agent knows the verb but not the mechanics.

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 0% – the schema offers only a bare integer named 'choice'. The description partially compensates by specifying the indexing base ('1-based index'), which is genuinely useful, but it omits the valid range and how the index maps to the displayed options.

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 specific verb (choose) and resource (NPC menu option), which is clear enough to act on. It does not explicitly differentiate itself from close siblings like npc_next or npc_input_int, so the agent must infer the boundary from the word 'menu option'.

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?

There is no statement of when this tool is appropriate versus npc_next, npc_input_str, or npc_input_int, all of which operate in the same NPC dialog flow. The only hint is the phrase 'NPC menu option', leaving selection entirely to inference.

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 exist, so the description carries the full burden. It does disclose the interesting behavior of the default sentinel and the stale-state use case, but says nothing about failure modes, what happens if the id is invalid, or any return/confirmation behavior.

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?

Two tight sentences, front-loaded with the action, followed by the parameter rule and a single parenthetical example. No filler and every clause earns its place.

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, no-output-schema, no-annotation tool, the description covers the action and the only parameter's semantics well. An agent has enough to call it correctly; only error/edge-case behavior is left unstated.

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 0% and the lone parameter has no description, so the description must compensate. It does so effectively, explaining that npc_id=0 is the default and means 'client-tracked NPC', while a nonzero id targets a specific NPC. This is exactly the semantic the schema is missing.

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 specific verb and resource ('Close NPC dialog'), clearly distinguishing it from open/next/choose dialog siblings. It does not explicitly distinguish from close_storage, which is a near-neighbor in the sibling list, but the core action is 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?

Gives explicit conditional guidance: use the default 0 for the client-tracked NPC, and pass an explicit id only when client state is stale. A concrete triggering scenario (storage NPC with no dialog packet) is provided. No explicit exclusions or named alternatives, so not 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 provided, the description carries the full burden of behavioral disclosure. It says input is submitted but does not state whether the dialog must already be open, whether the value triggers an action, what happens to the dialog after submission, or any side effects or permission requirements.

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 a single, front-loaded sentence with no wasted words. It is appropriately terse, though its brevity is a reflection of under-specification rather than efficient packing of necessary 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?

Given no annotations, no output schema, and 0% parameter description coverage, the description is incomplete for proper invocation. It omits what the integer value should represent, when the tool applies, and what behavior results, leaving significant gaps 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 description coverage is 0% for the single required parameter 'value'. The description only says 'integer input', which merely repeats the schema's type and adds no meaning about what the integer represents or how it is interpreted by the NPC dialog.

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 ('Submit') and resource ('integer input to an NPC dialog'), which clearly distinguishes it from the string variant sibling npc_input_str. It does not explicitly name the sibling or detail the dialog context, but the purpose is clear enough for an agent to identify the operation.

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?

No guidance is given on when to use this tool versus alternatives, no prerequisites (such as having an NPC dialog open), and no conditions or exclusions. The description only restates what the tool does.

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 does not state prerequisites (an active NPC dialog prompt), what happens on invalid or unexpected input, or any side effect on dialog state.

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?

A single front-loaded sentence with no filler. Brief, though arguably under-specified rather than truly concise.

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 simple one-parameter dialog tool with no annotations or output schema, the description is minimally viable, but it omits the dialog-context prerequisite and how this routes versus npc_input_int and npc_choose.

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 0% for the single 'text' parameter, but the description's phrase 'text input' loosely maps to it. Beyond that hint, no format, length, or expected-value guidance is added.

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?

Names a specific verb (Submit) and resource (text input to an NPC dialog), which is enough for an agent to identify it as the string variant alongside npc_input_int. It does not explicitly contrast itself with that integer sibling, so it falls short of a 5.

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?

No guidance on when the dialog expects text versus the sibling npc_input_int, nor any mention that an NPC dialog must already be open. Usage is only implied by the tool name.

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 behavioral burden. It states the action (advancing dialog) but does not disclose preconditions (e.g., must be in an active NPC dialog) or any side effects, leaving significant behavioral context unstated.

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 a single short sentence that front-loads the core action and includes a helpful parenthetical. Every word earns its place, with no redundant or filler text.

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 simple, parameterless dialog-advance tool with no output schema, the description is largely sufficient. It could mention the precondition of an open NPC dialog, but the name and description together convey the essential action, making it nearly 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 tool takes zero parameters, so there is no parameter semantics to explain. The baseline score for a 0-param tool is 4; the description correctly does not invent parameters or add unnecessary 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 verb ('Continue') and resource ('NPC dialog') plus the UI equivalent ('click Next'), making the tool's action clear. It does not explicitly differentiate itself from siblings like npc_choose or npc_close, so it stops short of a 5.

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 phrase '(click Next)' implies usage when a Next button is available in an NPC dialog, which is adequate context. However, it gives no explicit guidance on when to use this over alternatives like npc_choose or npc_close, nor any exclusions, so it remains implied usage rather than clear routing.

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 must carry the behavioral burden, and it does disclose the core trait: this is a read that returns the set of currently online players. However, it says nothing about whether the caller is included, whether the list is scoped to the current map or server-wide, or whether results are paginated or rate limited.

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?

A single sentence with no filler, and the key noun ('players currently online') is front-loaded. There is no structure to criticize, though it is so terse that it leaves useful context unstated rather than wasting words.

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?

No output schema exists, so the description reasonably should hint at what each entry contains (player names vs. identifiers, ordering), which matters because the result is likely an input to whisper or party tools. It only promises 'a list of players,' leaving the return shape entirely undefined.

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 declares zero parameters, so there is nothing for the description to disambiguate. The description correctly signals a no-argument call, matching the empty input schema. Baseline 4 applies for a parameterless 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 gives a specific verb and resource: 'Get list of all players currently online.' That is unambiguous and cannot be confused with action-oriented siblings like walk, attack, or trade_request. It stops short of explicitly contrasting with any sibling, but none competes with it, so clarity is high.

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 is only implied: an agent naturally infers it should call this when it needs the roster of connected players. There is no statement of when to prefer it over related queries such as state or inventory, and no mention of prerequisites or follow-up tools (e.g., using the result to whisper a player).

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 behavioral burden. It does not state whether the sender must be in a party, whether offline members receive the message, message length limits, or any failure modes, leaving important behavioral traits undisclosed.

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 a single, front-loaded sentence with no redundant text. It is efficiently sized for a simple tool, though its brevity is also the source of missing behavioral and usage detail.

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 low-complexity chat tool with one parameter, no annotations, and no output schema, the description is minimally adequate. However, it omits any relationship to the nearby party_reply tool and says nothing about party membership requirements or delivery behavior.

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 0% for the single required message parameter. The description says only 'a message', which restates the parameter concept without adding format, length, or content constraints. It does not compensate for the missing schema documentation.

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 specific verb (send), resource (message), and audience (party members), which implicitly distinguishes it from say and whisper. However, it does not name the sibling alternatives explicitly, leaving some differentiation to inference.

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 phrase 'to party members' implies the tool is for party chat rather than public or private messaging, but there is no explicit guidance on when to use this versus say, whisper, or party_reply. Usage is implied rather than stated.

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 behavioral burden, and it discloses almost nothing. It does not say whether leaving is irreversible, whether other members are notified, whether the agent must be in a party, or what happens on failure.

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 single sentence is front-loaded, unambiguous, and contains no filler. It is appropriately sized for a no-argument action, though it is terse enough that it leaves useful context unstated.

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-parameter, no-output-schema action, the description is just enough to identify the operation, so an agent can call it correctly. However, with no annotations to cover prerequisites or side effects, missing details such as the in-party precondition leave it minimally 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 tool takes zero parameters, so the baseline is 4 and there is nothing parameter-related for the description to compensate for. No extra semantics are needed or missing 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 states a specific verb (leave) and resource (party), so an agent immediately knows this exits the current party. It does not differentiate itself from siblings such as party_chat or party_reply, but those are clearly different actions, so the risk of confusion is low.

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?

There is no guidance on when to use this tool versus alternatives, nor any stated precondition such as being in a party. The usage is only implicitly obvious from the verb; nothing tells the agent what to do if it is not currently in a party.

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 falls short. 'Accept or reject' implies a state-changing action but the description never says what happens on accept (do you join the party? is the inviter notified?), whether an invitation must be pending, or what occurs if it fails.

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?

A single, front-loaded sentence with no filler or redundancy. It is arguably too terse for the behavioral gaps it leaves, but nothing in it is 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 two-parameter action tool with no output schema and no annotations, the description is minimally sufficient to pick the tool but incomplete: it omits precondition (a pending invite), post-call effect, and the account_id parameter.

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 0%, but the description directly covers the 'accept' boolean by describing the accept/reject choice, which is the essential semantic. The required 'account_id' is left entirely undocumented and there is no note on the default=true behavior.

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 specific verb pair (accept/reject) and resource (party invitation), so an agent can immediately tell this handles responding to an invitation. It is reasonably distinguishable from siblings like party_leave and party_chat, though it never names them.

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?

Implies usage (you must have a pending invitation) but never states when to call it versus alternatives such as party_leave or trade_accept, nor what precondition must hold. No exclusions or alternatives are offered.

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 behavioral burden, and it discloses almost nothing: it does not say where the item goes (inventory?), what happens on failure (item gone, inventory full, out of range), or whether the operation is repeatable. Only the bare action is conveyed.

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?

A single front-loaded sentence with zero filler; the action and its target are stated immediately. It is terse to the point of under-specification, but nothing in it is 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 tool with no annotations, no output schema, and an entirely undocumented parameter, the description is too thin to be self-sufficient. It omits return/effect information and failure conditions that an agent needs before invoking it in a game state.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single parameter, so the description must compensate. It does add one useful semantic — the ID refers to a floor/map item rather than an inventory slot — but gives no detail on range, validity, or what the ID corresponds to in the game world.

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 specific verb (pick up) and resource (a floor item) with the key identifier (ID). It is clearly distinguishable from the inverse tool 'drop' and from inventory tools like 'use'/'equip', though it never explicitly contrasts itself with them.

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?

No when-to-use guidance, no prerequisites, and no alternatives named. Nothing tells the agent whether it must be standing on/near the item, whether a weight or inventory-space limit applies, or how this differs from picking items up via a shop/NPC flow.

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 behavioral burden, yet it only states the trigger condition. It says nothing about where the character reappears, whether items/XP are affected, or any cooldown or cost, which are the typical behavioral traits an agent would need for a respawn command.

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?

It is a single front-loaded sentence with zero filler, which is good, but it is so sparse that 'appropriately sized' is questionable for a command that has behavioral implications. It avoids the empty tautology of a bare name but does not build any structure beyond the trigger clause.

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 zero parameters, no annotations, and no output schema, low complexity means less is required, and the trigger condition is the key piece an agent needs. Still, the description omits outcome and restriction details (respawn location, penalties, cooldown) that would make invocation unambiguous in a game 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 tool takes zero parameters, which sets the baseline at 4 per the scoring rules. There is no parameter information the description could add, so no deduction is warranted.

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 specific verb ('Respawn') and the triggering context ('after death'), so an agent can tell what the tool does without opening anything. It does not explicitly differentiate itself from the sibling 'restart', which is the closest ambiguity, so it falls short of a 5.

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 phrase 'after death' gives an implied trigger condition, which is useful usage context. However, there is no explicit when-not guidance, no mention of prerequisites such as cooldowns or costs, and no routing to the sibling 'restart' if the character is not dead, leaving the agent to infer edge cases.

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. It usefully discloses the mechanism and consequence ('sends a clean quit to the map server so re-login succeeds immediately'), but says nothing about what is lost — in-flight trades, party state, or whether the connection drops — which matters for a disruptive 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?

Three tightly packed sentences with the action front-loaded, then the mechanism, then the trigger condition. No filler or restatement 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?

For a zero-parameter, no-output-schema tool, the description covers what happens, why it works, and when to invoke it. The only missing element is the scope of disruption to current bot activity.

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 is nothing for the description to disambiguate. Baseline 4 applies; the description correctly does not invent parameter 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?

States a specific verb and resource ('Hard-restart the TMW bot daemon'), which is unambiguous and easily distinguished from every sibling in the list — none of the other tools restarts the daemon.

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?

Explicitly names the triggering conditions ('when the bot is wedged or after a code change'), which tells the agent when to reach for it. No alternative tool is named, but no sibling performs an equivalent function, so there is nothing to route against.

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 behavioral burden. It discloses only that the message is public (visible to others), but says nothing about character limits, rate limits, spam/cooldown behavior, or error conditions for an in-game chat action.

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?

A single front-loaded sentence with zero padding. It is efficient, though the brevity borders on under-specification rather than deliberate conciseness.

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 one-parameter chat tool with no output schema and no annotations, the description is minimally sufficient to invoke it correctly. It nonetheless omits channel scoping and any input constraints an agent would want before sending a message.

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 0% and the single parameter ('message') is documented nowhere beyond its name. The description adds no meaning such as length constraints, formatting, or command-prefix behavior, so it fails to compensate for the schema gap.

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 gives a specific verb ('Send') and resource ('public chat message in-game'), which is unambiguous about what the tool does. The word 'public' implicitly distinguishes it from siblings like whisper and party_chat, but it never names them, so differentiation is left to inference.

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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternatives among the many chat-related siblings (whisper, party_chat, party_reply). The 'public' qualifier hints at the contrast with private channels but never states it, leaving the agent to infer routing.

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 sequencing prerequisite, which is useful, but says nothing about the fact that selling mutates inventory by removing items, whether failures are possible, or how many items will be sold by default.

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?

Two short, front-loaded sentences with no filler; the primary action leads. Minor noise from the 'tmw_shop_sell' internal-name reference, but overall efficient.

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 mutating sell tool with no annotations, no output schema, and fully undocumented parameters, the description is too thin. It should at least clarify the index/count semantics and what selling does to inventory.

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 0% for two parameters, including the required 'index'. The description never explains what index refers to or how count interacts with it, so it fails to compensate for the schema gap.

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 clear verb+resource ('Sell items to shop'), so the agent knows the action immediately. However, it does not distinguish itself from the sibling tool shop_sell, and the referenced 'tmw_shop_sell' does not exactly match any sibling name, leaving the relationship ambiguous.

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 a concrete prerequisite: the sell list must be opened first via tmw_shop_sell. That is real when-to-use context. It stops short of naming alternatives or stating when NOT to use this versus shop_sell/buy.

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. It does disclose the workflow precondition and the side effect ("The buy list will appear in game state"), which is useful. But it omits whether the call mutates state beyond opening the list, any authentication/permission needs, or error behavior.

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?

Three short sentences, purpose front-loaded, each carrying distinct information (purpose, precondition, outcome). No filler; only minor room to restructure.

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 one-parameter, no-output-schema tool the description covers purpose, trigger, and side effect, which is adequate. It still leaves the parameter undefined and does not distinguish shop_buy from the sibling buy tool, so it is minimum-viable rather than 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?

Schema description coverage is 0% and the single parameter npc_id is undocumented. The description references "a shop NPC" but never explains what npc_id is, its format, or where to obtain it, so it fails to compensate for the schema gap.

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 specific verb and resource ("Open a shop NPC's buy list"), which tells the agent what happens and to which object. However, it does not differentiate from the sibling "buy" tool, leaving the agent unclear on why both exist.

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 a clear precondition: "Use after clicking a shop NPC (0x00c4 event)." This is genuine when-to-use guidance. It lacks exclusions or explicit alternatives (e.g., shop_sell for selling, buy for purchasing), 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?

No annotations are provided, so the description carries the full behavioral burden. It names the trigger event but does not disclose whether this mutates state, what permissions or NPC state are required, whether it is read-only, or what happens to any open shop UI; this is a significant gap for a state-opening action.

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?

Two short sentences, front-loaded with the action and followed by the necessary trigger context. No redundant or filler text.

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 simple one-parameter opener with no annotations or output schema, the description covers purpose and invocation context but leaves clear gaps in parameter provenance and behavioral effects. It is minimally viable but not fully self-contained.

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 0% for the single required npc_id parameter. The description only indirectly implies npc_id identifies the clicked shop NPC; it does not explain the parameter's format, how to obtain it from the 0x00c4 event, or what values are valid.

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 and resource: opening a shop NPC's sell list. It is clear what the tool does, but it does not explicitly distinguish this tool from the sibling 'sell' or 'shop_buy' tools, leaving some ambiguity about whether it selects the sell tab or initiates a sale.

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 a clear precondition: use after clicking a shop NPC (0x00c4 event). This tells the agent when the tool is valid, though it offers no when-not guidance or alternative tools for different shop interaction paths.

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, yet it reveals nothing beyond the verb itself: no state change, prerequisites (e.g., must be standing), interruption effects, or interaction with other actions. This is the same level of disclosure as a bare 'Process' 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?

At two words, it is front-loaded and free of bloat, but it is under-specified rather than concise in a useful sense. It adds essentially nothing beyond the tool name, so the brevity reflects a lack of content rather than efficient communication.

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 simple action tool with no annotations and no output schema, the description still omits the information an agent needs: whether sitting is always permitted, what state it changes, and how it relates to 'stand' or movement. It is not complete enough to invoke reliably without guessing.

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 to explain; per the rubric, a zero-parameter tool starts at baseline 4. The schema coverage is also 100%, so no compensation is needed.

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 action verb ('sit'), making the tool's basic function clear, but it offers no differentiation from siblings like 'stand', 'walk', or 'face', which are the likely alternatives an agent must choose between.

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?

There is no guidance on when to use this tool, when not to, or which sibling to prefer. The agent is left to infer that 'stand' is the inverse and that this tool is only valid in certain states.

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 of behavioral disclosure, and it says nothing beyond the verb. It does not state what state is required (must be sitting?), whether it affects combat or movement eligibility, or what happens if already standing.

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?

Two words, front-loaded and free of filler, but the brevity reflects under-specification rather than tight structure. There is no sentence earning its place because there is only one fragment.

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-parameter posture action, the description is incomplete: it omits state preconditions, side effects on movement/combat, and any output expectation. With no annotations and no output schema, the description should have done more of this work.

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 is no parameter semantics for the description to explain; the baseline of 4 applies. Nothing is missing or contradictory in the 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?

"Stand up." essentially restates the tool name (stand) with no additional specificity. It does imply a change of posture in a game context, which loosely distinguishes it from siblings like sit, but an agent gets no more information than the name already conveys.

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?

No when-to-use, prerequisites, or alternative routing is provided. The description gives no hint that this is the inverse of sit or that it interacts with movement actions like walk.

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 behavioral burden. It discloses the mutation ('Increase') but not whether the change is permanent, whether it consumes stat points, whether it costs zeny, or what the result looks like.

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?

One short sentence with the action front-loaded and the value domain appended. Nothing is 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 one-parameter mutation tool with no annotations and no output schema, the description is barely adequate. It covers the target domain but omits the cost/effect semantics (how much the stat increases, what resource is spent) that an agent would need to call it 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 0% and the single parameter has no enum, so the description's enumeration of the six valid stat names (str, agi, vit, int, dex, luk) supplies information the schema lacks entirely. It does not clarify casing or abbreviation rules, but the allowed domain is covered.

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 specific verb ('Increase') and resource ('stat'), and enumerates the six valid stat targets. No sibling tool deals with character stats, so no differentiation is required, but it stops short of stating the effect magnitude or cost.

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?

There is no explicit when-to-use or when-not-to-use guidance. The usage is only implied by the verb 'Increase'; nothing tells the agent about prerequisites such as available stat points or level requirements.

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. 'Get' implies a read-only query, and it usefully enumerates the observation payload, but it says nothing about side effects, permission/auth requirements, or rate limits. Adequate for a simple getter but not rich.

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?

A single front-loaded sentence with no filler; the verb and resource lead and the enumerated contents follow. Every element earns its place.

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 input parameters and no output schema, the description partially compensates by naming the return contents (character info, position, HP/SP, nearby beings, floor items). For a simple read tool this is close to sufficient, though exact field formats remain unspecified.

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 the baseline is 4. There are no argument semantics to clarify and the description does not need to compensate for any schema gaps.

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 specific verb ('Get') and resource ('current game state') and enumerates the contents returned: character info, position, HP/SP, nearby beings, floor items. It overlaps with siblings like stat, map, and inventory but does not explicitly differentiate itself from them.

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 is implied by the name and description — call it to observe the current situation — but there is no statement of when to prefer this over overlapping siblings such as stat, map, or inventory, and no prerequisites or exclusions are given.

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 disclosure burden. It does disclose the behavioral effect precisely (it stops both auto-attack and hunting), which is useful, but it omits what happens if the character is not currently attacking/hunting (error vs. no-op) and any resulting state change or response.

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?

A single short sentence with zero filler, front-loading the verb and the affected actions. Appropriate sizing for a zero-argument command.

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-parameter, no-output command, the description covers the essential behavior. It could add a note on the no-op/error case or its relationship to the attack/hunt siblings, but nothing critical for invocation 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?

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description correctly implies a no-argument command, consistent with the 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 states a specific verb (stop) and the exact resources affected (auto-attack and hunting), so an agent can distinguish it from the sibling 'attack' and 'hunt' tools by inversion. It does not explicitly name those siblings, but the scope is 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?

Usage is only implied: an agent can infer it should be called when it wants to cancel an ongoing auto-attack or hunt. There is no explicit when-to-use statement, no mention of prerequisites, and no comparison to alternatives such as simply issuing a different action.

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 of disclosure. "Accept" implies a state mutation of an existing trade session, but the description says nothing about prerequisites, whether acceptance is reversible, what happens if no request is pending, or whether the trade window opens afterward.

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?

A single, front-loaded sentence with no filler or repetition. It is efficient, though its brevity reflects under-specification rather than true conciseness of content.

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 state-machine action embedded in a multi-step trade workflow (request → accept → add item/zeny → lock → commit), the description omits the ordering, prerequisites, and outcome. With no annotations and no output schema, nothing else compensates for those gaps.

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 to document and the baseline of 4 applies. The empty schema is consistent with the description.

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 ("Accept") and resource ("incoming trade request"), which is clearly distinguishable from siblings like trade_request, trade_reject, and trade_cancel. However, it does not differentiate itself from trade_commit, which is the closest plausible alternative in the same workflow and could easily be confused with this one.

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?

There is no guidance on when this tool is valid (e.g., a pending incoming request must exist, presumably created by trade_request) or how it relates to trade_commit/trade_lock later in the sequence. The agent must infer the trade workflow from sibling names alone.

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. It does disclose the useful amount=0 default (whole stack), but says nothing about whether the item leaves inventory, whether the action is reversible, what errors occur if no trade is open, or rate/state constraints on a mutation.

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?

A single compact sentence with no filler, and the important default is placed in a parenthetical right where it matters. Nothing is wasted, though it is arguably too terse given the unexplained index parameter.

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 mutation tool with no annotations, no output schema, and one of two parameters undocumented. The description does not cover prerequisites or the effect on inventory, so an agent lacks enough to invoke it confidently in the trade workflow.

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 0%, so the description must compensate. It explains 'amount' well (0 = entire stack), but 'index' is left completely undefined — the agent cannot tell whether it indexes inventory slots, trade slots, or something else.

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 specific verb+resource ('Add an inventory item to the trade offer'), which is clear and distinguishable from siblings like trade_add_zeny or trade_commit. It stops short of naming the alternative operations, but the core action is 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?

No guidance on when to use this versus trade_add_zeny, or on prerequisites such as having an open/active trade or needing trade_lock before commit. The user must infer the flow from the other trade_* siblings.

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 delivers only one clause. It does not say whether the player must own that much zeny, whether the amount is validated or capped, whether re-calling overwrites the offer, or whether a lock is required — all material for a mutation in a trade lifecycle.

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?

A single short sentence with the action and target front-loaded and zero filler. Nothing is redundant or buried.

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 state-mutating trade tool with no annotations, no output schema, and an undocumented parameter, this is far too thin. It omits preconditions, failure modes, and interaction with trade_lock/trade_commit, leaving the agent to guess the operating 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?

Schema description coverage is 0% for the single 'amount' parameter, so the description must compensate; 'zeny (GP)' does clarify the unit/currency being added, which is real added value. It still omits valid ranges (positive only? bounded by player's funds?) and whether the value is absolute or incremental.

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 specific verb (Add) and resource (zeny/GP) with the target context (the trade offer), which implicitly separates it from trade_add_item. It stops short of explicitly naming that sibling or the surrounding trade flow, but an agent can tell what it mutates.

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?

No when-to-use guidance, no prerequisites (an open trade session), and no indication of how it relates to siblings like trade_lock, trade_commit, or trade_cancel. The agent must infer the trade sequence entirely from other tools.

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 disclosure burden. It says nothing about whether items already added are returned to inventory, whether the other party is notified, whether the action is reversible, or what errors occur when no trade is active.

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?

A single front-loaded sentence with zero filler, which is appropriate for a no-argument action. It is arguably too terse for the behavioral burden it must carry, but nothing in the text is 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 zero-parameter, no-output-schema action, the description tells the agent enough to invoke it correctly. However, with no annotations and a cluster of similarly named trade_* tools, it leaves side effects, prerequisites, and sibling selection entirely to inference.

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 is nothing for the description to disambiguate and the schema is trivially complete. Baseline of 4 applies; no parameter content is needed.

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 specific verb (cancel) and resource (the current trade), which is enough for an agent to know this aborts the in-progress trade session. It does not explicitly distinguish itself from close siblings like trade_commit (finalize) or trade_reject (decline a request), so the agent must infer the difference from the names alone.

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?

There is no when-to-use guidance, no prerequisites (e.g. an active trade must exist), and no mention of alternatives such as trade_commit or trade_reject. The agent gets no help choosing among the several trade_* siblings.

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. It discloses the important precondition (both sides locked), which is valuable context beyond the schema. However, it does not state the consequences of committing (e.g., finalizing the exchange, irreversibility, or error behavior if not locked), leaving meaningful gaps for a state-changing action.

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?

A single, front-loaded sentence with zero wasted words. It communicates the action and the precondition immediately.

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 parameters, no annotations, and no output schema, the description must carry the full context. It provides the precondition but omits what commit actually does (finalize the trade) and its irreversible nature. Adequate for basic invocation but incomplete for a critical final action.

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 is no parameter semantics to explain. The schema is trivially complete, and the baseline for zero-parameter tools is 4.

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 (commit) and resource (trade), and the precondition 'after both sides have locked' distinguishes it from sibling actions like trade_lock, trade_cancel, and trade_accept. It is clear what the tool does, though it does not explicitly name the siblings it is not.

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 an explicit condition for invocation: only after both sides have locked. This is clear usage context. It does not mention alternatives or what to do if the precondition is not met, but the key gating condition is stated.

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 must carry the full behavioral burden. It only states that the tool locks your side of the trade and indicates readiness to commit; it does not describe whether the action is reversible, what happens after locking, whether it requires the other party to act, or any side effects or permissions.

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 a single, front-loaded sentence with no wasted words. It efficiently conveys the core action and its intended meaning.

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, no output schema, and no parameters, the description carries the entire burden of explaining behavior. It is too minimal for a state-changing trade action: it omits the sequence with related tools (e.g., trade_request, trade_accept, trade_commit), what locking entails, and any conditions or consequences.

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 and schema description coverage is effectively 100% (nothing to document). Per the rubric, 0 params yields a baseline of 4; the description adds no parameter details because none exist.

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 and resource: 'Lock your side of the trade.' The parenthetical clarifies the purpose as indicating readiness to commit, which implicitly distinguishes it from trade_commit. However, it does not explicitly name trade_commit as a distinct sibling, so the differentiation is not fully spelled out.

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 phrase 'indicate readiness to commit' implies the condition under which the tool should be used, but it does not explicitly compare against alternatives such as trade_commit or explain when not to use it. Usage is only implied, not directly stated.

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 discloses almost nothing: it doesn't say whether the counterparty is notified, whether the request is destroyed or just declined, or what state the caller must be in. 'Reject' implies a state change but no consequences are described.

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?

A single sentence with no waste, front-loaded with the verb. It is efficient, though its brevity reflects under-specification rather than discipline.

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?

The tool is simple (no params, no output schema, no annotations), so minimal text is defensible, but the description still leaves open the distinction from trade_cancel and any side effects on the other party.

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 is nothing for the description to disambiguate. Baseline of 4 applies.

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 specific verb (reject) and resource (incoming trade request), so the agent knows the action. However it does not distinguish itself from sibling trade_cancel, which an agent could easily confuse with rejecting a request.

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?

No when-to-use guidance, no prerequisites, and no exclusion of alternatives. Nothing tells the agent whether this applies to an incoming request versus a trade it initiated, which is exactly the ambiguity trade_cancel creates.

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 behavioral burden, and it discloses almost nothing: not what the target sees, whether a trade window opens, whether the request expires, or how to cancel it. For a stateful multiplayer action this is a significant gap.

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?

A single well-formed sentence with the action and its input front-loaded and no filler. It is efficient, though its brevity is partly the cause of the missing behavioral and usage context.

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, no output schema, and a bare parameter, the description should explain the request/accept lifecycle and any range or online requirements. It omits all of this, leaving an agent unable to predict the outcome of the call.

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 0% and the schema itself only says 'target: string', so the description's clarification that this is a player name is genuinely additive. However, it gives no format detail (exact spelling, case sensitivity, self-targeting) to compensate for the undocumented 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?

States a specific verb (request) and resource (player-to-player trade) plus the input (player name). An agent can distinguish it from trade_accept/trade_reject as the initiating step, though the description never names those siblings to make the lifecycle explicit.

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?

No when-to-use guidance, no prerequisites (target must be online, in range), and no mention of the follow-up flow through trade_accept/trade_reject/trade_commit even though those siblings exist. Usage is only weakly implied by the word 'Request'.

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 behavioral burden, and it discloses nothing. It does not say whether the item is consumed/destroyed, whether the action is reversible, whether a target must be selected, or whether it can be used in combat.

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?

A single short sentence with the action and its key qualifier front-loaded; no filler or redundancy. It is appropriately sized, though its brevity is partly a symptom of under-specification rather than true economy.

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 state-mutating game action with no annotations, no output schema, and no documented parameters, the description is far too thin. An agent cannot tell what effect using an item has or what happens on failure, which is essential for this class of 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?

Schema coverage is 0% and the schema only labels the field "index". The phrase "inventory index" usefully compensates by clarifying that the index identifies a slot in the inventory, but it omits whether indexing is 0-based, its valid range, and whether it refers to the item's position or its ID.

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?

"Use an item by inventory index" states a verb and resource plus the identifying mechanism, so the basic action is discernible. However, it gives no differentiation from the many sibling item-manipulation tools (equip, drop, shop_sell), and "use" is ambiguous for a game action (consume vs. activate vs. apply to a target).

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?

There is no statement of when to call this tool versus alternatives such as equip (wear gear) or drop (discard). The agent must infer that "use" means consuming/activating an item and that equip/drop cover the other cases.

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 disclose two useful traits: routing uses A* and the call signals completion or failure via a channel notification, so the agent knows failure is possible. It omits whether the call blocks until arrival, timeout behavior, what happens if the path is blocked, and any permission requirements.

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?

Two short sentences, front-loaded with the action and mechanism, with the arrival/failure notification as supporting detail. No filler or redundancy.

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 an unannotated, output-schema-less tool with undocumented parameters, the description covers the mechanism and the failure notification but leaves blocking semantics, timeout, and pathing-failure behavior undefined. Adequate to attempt a call, incomplete for predicting its behavior.

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 0%, so the schema provides only bare integer types for x and y. The description adds only that these are coordinates, with no map context, units, valid bounds, or distinction from other coordinate-bearing siblings.

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?

"Walk to coordinates (x, y)" is a specific verb plus resource, and naming A* pathfinding tells the agent this is a routed movement action rather than teleportation. It implicitly separates itself from siblings like follow or sit, but never explicitly contrasts with them.

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?

There is no statement of when to use this versus alternatives such as follow (which is also movement-oriented), nor any prerequisites like needing a valid navigable path or being in a state that permits movement. Usage is only inferable from the verb.

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 discloses almost nothing: no statement about whether the target must be online, what happens if the player is not found, whether delivery is confirmed, or any rate limits. 'Send' implies an action but no failure or side-effect behavior is described.

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?

A single short sentence with no wasted words and the key noun front-loaded after the verb. Brevity here reflects under-specification rather than disciplined editing, so it is efficient but thin.

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 an action tool with no annotations, no output schema, and 0% parameter coverage, the description leaves critical call-time questions unanswered (target resolution, offline behavior, delivery confirmation). It is too sparse for a tool in a crowded sibling set of chat and interaction commands.

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 0%, so both parameters are undocumented. The description only implicitly narrows 'target' to a player (vs. an ID or channel) and says nothing about message length, formatting, or how partial/ambiguous names are resolved.

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 gives a specific verb ('send') and resource ('private message') targeting a player. The word 'private' implicitly separates it from public-channel siblings like say, though it never names those siblings explicitly.

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?

There is no explicit when-to-use or when-not-to-use guidance, despite siblings say, party_chat, and party_reply occupying adjacent chat roles. The agent must infer from 'private' that this is a direct one-to-one channel rather than a broadcast or party channel.

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