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

With no annotations, the description carries the full behavioral burden and does add useful context: it only considers explored ground, and it notes that missing-ingredient details are included only 'when detectable.' It does not explicitly state whether the operation is read-only or whether it has side effects, which is a meaningful gap for an unannotated tool.

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 one front-loaded sentence with zero filler. Each problem category earns its place, and the 'when detectable' parenthetical is a useful precision rather than wasted 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 analysis tool, the description covers the main behavioral constraints: explored ground, the full set of problem groupings, and the power summary. The output schema presumably covers the return shape, so the description is largely complete, though the radius parameter and explicit read-only status could be clarified.

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 only parameter, radius, is not mentioned in the description; 'in an area' hints at it but does not explain units, effect, or default behavior. Since schema description coverage is 0%, the description should compensate for the missing parameter explanation and does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool reports: machines in an explored area grouped by problem categories, plus a power summary. It does not explicitly differentiate from siblings like production_stats or scan_area, but the focus on problem-grouping makes the intent distinct.

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 implies that this tool is for diagnosing factory machine issues in an explored area, and the explored-ground caveat gives useful context. However, it does not explicitly say when to use this tool instead of alternatives such as inspect_entity, scan_area, or production_stats.

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 behavioral burden. It discloses that the blueprint is built as one job, that the top-left entity is anchored, that there is a 1000-entity limit, and that per-step failures are reported. It does not cover queueing, cancellation, permissions, or side effects, but the key behavioral traits are 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?

Two sentences with no filler. The most important behavior (whole-blueprint, one-job, anchored) is front-loaded, followed by source modes, limits, and error reporting. 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 an 8-parameter job-building tool, the description is reasonably complete: it explains the core flow, limits, and failure reporting. The output schema covers return values, so that burden is lifted. Minor gaps remain around the 'book' parameter and the precise meaning of 'carried blueprint by label', but the description is sufficient for an agent to use it correctly in most cases.

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 description adds meaning beyond the schema by explaining the anchoring semantics ('top-left entity lands at anchor_x, anchor_y') and the two source modes ('export string' or 'carried blueprint by label'). Schema coverage is partial at 63%, and the description helps compensate for some undocumented parameters, though book, replace, wait_s, and stop_on_error remain mostly schema-dependent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Build a whole blueprint as ONE job') on a specific resource, with anchoring behavior and input sources specified. It distinguishes this from sibling tools like build_plan or import_blueprint by emphasizing whole-blueprint, job-based execution.

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 clear context for when to use the tool: when you want a whole blueprint built as a single job, from either an export string or a carried blueprint label. It does not explicitly name alternatives or say when not to use it, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden and does so well: it explains ordered placement, failure reporting/skipping unless stop_on_error, auto_craft hand-crafting missing items, and dry_run validation behavior. These traits go well beyond the schema (which only describes wait_s and replace) and give the agent a clear model of side effects.

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 dense, front-loaded paragraph where the opening phrase states the core purpose and subsequent clauses add behavioral detail. It avoids redundancy and every sentence earns its place, though the phrase 'normal placement rules' is somewhat vague and could be more explicit.

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 an output schema, the description covers the key execution semantics: step ordering, placement constraints, per-step recipe/insert, failure behavior, auto_craft, and dry_run. It does not explicitly describe coordinate semantics (x/y) or the maximum step count, but those are present in the schema, making the description sufficiently complete for correct invocation.

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 only 33%, yet the description compensates for the three Boolean parameters (dry_run, auto_craft, stop_on_error) by explaining their runtime meaning. However, it does not clarify the 'direction' field in BuildStep or the full step object structure, and it adds little beyond the schema for wait_s and replace, so the compensation is only partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Build many entities as ONE job', which clearly states the verb (build), the resource (many entities), and the batch nature that distinguishes it from single-placement siblings like place_entity. It further specifies that each step can optionally set a recipe and insert items, leaving no ambiguity about what the tool does.

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 implies usage for batch building ('many entities as ONE job') but does not explicitly mention when to prefer it over alternatives such as place_entity, build_blueprint, or run_plan. It also omits any exclusion criteria or 'when not to use' guidance, so the agent must infer the appropriate 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?

With no annotations, the description carries the burden and does well: it discloses no side effects, caps at 24 placements per call, and describes the response shape (yes/no with blocker). It does not cover all edge cases (e.g., errors when positions are un-explored), but key behaviors are clearly stated. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The first sentence leads with purpose and side-effect status; the second adds batch limit and response format. Every word 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 query tool with an output schema, the description covers the essential operational constraints (no side effects, max batch, response semantics) and the scope ('explored positions'). It doesn't explain coordinate system or item selection details, but those are likely in the schema or game context, so the description is sufficiently 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%, so the description must compensate. It adds the batch limit for the placements parameter and connects items/positions to the tool's purpose, but it does not explain x, y, item, or direction beyond what the schema's direction description already provides. Partial compensation.

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 ('check'), resource ('items... at explored positions'), and a defining constraint ('no side effects'), which distinguishes it from mutation siblings like place_entity and build_plan. An agent can immediately tell this is a feasibility query, not an action.

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 clear context for when the check is valid ('right now', 'explored positions') and batch limits, but does not explicitly name alternatives or when-not-to-use, leaving usage to be inferred from purpose. The sibling tool place_entity is an obvious alternative but is not referenced.

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. It does not state that this is a read-only operation, what data it returns, or any side effects. The agent is left to infer that 'check' means viewing, which is not explicitly 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?

While short, this is under-specification rather than concise efficiency. The single sentence does not earn its place because it merely identifies the resource without providing actionable information. It could have been replaced with a description that states the action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even though an output schema exists, the description should still clarify what the tool does. With no annotations and a vague description, the agent lacks critical context about the tool's behavior. For a simple no-parameter tool, this is 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?

The tool has zero parameters and the schema is 100% covered (an empty object). According to the calibration, a baseline of 4 is appropriate for tools with no parameters, and the description does not need to add 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?

The description 'Your character's inventory and equipment.' is a noun phrase that restates the resource named by the tool. It does not state an action like 'retrieve' or 'list', so it is closer to a tautology than a clear purpose statement. It also fails to distinguish from sibling tools like 'equip' or 'extract_items' that interact with the same inventory.

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. An agent cannot tell whether to call check_inventory or equip/look_around based on the description. There are no exclusions or context 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?

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: real crafting time, missing intermediates are queued automatically, and the queueing behavior. It also hints at the wait_s parameter's effect by mentioning 'real crafting time' and queueing. It doesn't mention cancellation or replace behavior, but the schema already documents replace. The description adds meaningful behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence with high information density. It front-loads the core action and includes the most important behavioral caveats (real time, queued intermediates) without waste. 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?

The tool has an output schema, so return values are covered elsewhere. The description covers the key behavioral aspects: real crafting time, queueing, and intermediate handling. It doesn't mention prerequisites like having the blueprint or materials, but the queueing of intermediates implies material handling. For a 4-parameter tool with an output schema, this is 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?

Schema description coverage is 50%: wait_s and replace have descriptions, but count and recipe do not. The description adds context that 'missing intermediates are queued too', which relates to recipe semantics, but doesn't explain what a recipe string looks like or how count interacts with queued intermediates. It partially compensates for the schema gap but not fully.

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 ('Hand-craft') and resource ('your character's crafting queue'), and distinguishes it from other crafting-related tools like set_recipe and build_blueprint by emphasizing the character's personal queue and real crafting time. It doesn't explicitly name a sibling alternative, but the scope is clear enough to differentiate it from factory/entity crafting.

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 implies when to use it: when you want the character to craft items personally, with real time and queued intermediates. It doesn't explicitly state when not to use it or name alternatives like set_recipe for entity crafting, but the context is reasonably clear. No explicit exclusions or alternative 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 carries the burden and discloses key traits: it returns resources to inventory, uses vanilla mining time, targets only the force's own buildings, and enforces max 10 tiles/50 buildings. It doesn't explicitly mention that it returns a job id or can block on wait_s, but the schema's wait_s description covers that 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?

One dense, front-loaded sentence conveys target, behavior, mode selection, and limits with no filler. 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?

The definition is complete enough for selecting and starting a deconstruction job: it covers what is affected, where, how many, and the time model. Return-value details are not needed in the description because an output schema exists and the wait_s parameter already explains the job-id 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 coverage is 80%, so the baseline is 3, but the description adds meaningful semantics by defining the relationship between x/y and area_radius: nearest single building vs. all within radius. It also adds the practical limits of 10 tiles and 50 buildings that are not fully captured by the bare range constraints in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses a specific verb-object pair: 'Mine ... buildings back into your inventory', which clearly identifies the action and target. It distinguishes this from sibling tools like mine (natural resource extraction) and build_blueprint/place_entity by limiting to 'your force's own buildings' and noting 'vanilla mining time'.

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 clear operational contexts: use coordinates to target the nearest building, or area_radius to deconstruct all buildings in an area. It does not explicitly name an alternative tool or state when not to use it, but the 'own buildings' restriction effectively separates it from mining raw resources.

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 well: it discloses persistence until cancellation, the job-replacing side effect, the three guard actions, and that inventory is consumed for refills/repairs. It does not state how the job ends beyond cancellation or whether it can coexist with other jobs, but the key mutating behaviors are surfaced.

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 tight sentence that front-loads the purpose ('Persistent job: guard an area') and packs behaviors and the job-replacement side effect into the remainder. No filler; every clause adds 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?

Behavior and side effects are well covered and an output schema exists, so return values need no explanation. However, parameter semantics are a real gap in a 3-parameter tool where x/y are nullable and defaulted — an agent can call it safely with no args, but cannot target a specific area without guessing. Adequate overall, but not 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 coverage is 0% and the description never mentions x, y, or radius, so the agent receives no meaning beyond raw schema defaults (null/null/16, radius bounded 8-32). It must guess that x/y denote the area center and radius its size, plus units. The description should have mapped the guarding concept onto these parameters.

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 ('guard') and resource ('an area'), and enumerates concrete behaviors: shoot enemies, refill ammo turrets, repair structures from inventory. The 'Persistent job' framing plus 'Replaces your current jobs' clearly distinguishes it from immediate-action siblings like fight and from follow_player.

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 persistent/cancellable job framing implies when to use it (ongoing area defense), but no alternative is named and no when-not-to-use guidance is given. An agent must infer that fight is for immediate combat and job_cancel for stopping this job. Guidance is implied, not explicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does a good job: it explicitly discloses the batch limit, the categories of information returned, and that recipes include whether they are unlocked. It does not mention what happens for unknown names or partially-applicable prototypes, but for a read-only describe tool this is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every clause earns its place by adding concrete output details. It is front-loaded with the core claim ('Everything about up to 10 names at once') and then expands into specifics. It could be more readable as structured bullets, but there is no fluff or repetition.

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 read-only lookup tool with an output schema, the description covers the essential aspects: the query unit (names), the batching limit, and the returned data categories. It does not discuss error behavior or exact name format, but the combination of the detailed description and existing output schema is sufficient for an agent to invoke the tool correctly in most cases.

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 only says the parameter is an array of strings, with 0% schema coverage. The description adds valuable constraints ('up to 10 names') and implies the names refer to item/entity/recipe prototypes. However, it never clarifies exactly what a valid 'name' is or whether these are internal prototype names, localized names, or something else, so it only partially compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('describe'), a specific resource ('prototype'), and a clear scope ('up to 10 names at once'). It goes further than the tool name by enumerating exactly what is returned: item properties, entity properties, and the crafting recipe. This makes its purpose unmistakable and clearly separate from narrower or action-oriented siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for bulk lookup of full prototype details ('Everything about up to 10 names at once'), which gives useful context. However, it never states when to prefer this tool over alternatives such as inspect_entity, nor does it give exclusions or conditions. The usage guidance is implied rather than explicit.

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

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

With no annotations, the description carries the behavioral burden and does disclose meaningful side effects: boarding a free car and consuming inventory fuel when needed. However, it does not mention the async job behavior implied by wait_s and replace (queueing, cancelling, returning a job id), nor what happens if no free car is available.

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 one tight sentence that front-loads the core action and includes only the essential behavioral nuance about fuelling. There is no filler, redundancy, or off-topic 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?

The description plus the rich schema and output schema provide enough to attempt a basic call, but the definition lacks explicit guidance on alternatives and fails to surface the job-queue/cancellation semantics. It is minimally viable but has clear contextual 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 80%, which meets the high-coverage baseline of 3. The description only loosely refers to the destination as a 'position' and adds no detail on coordinate format, wait_s, replace, or arrive_within; the schema already documents those adequately.

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 ('board'), a concrete resource ('nearest free car'), and a destination ('drive to a position'). It also adds the non-obvious sub-action of fuelling from inventory, clearly distinguishing this from movement siblings like walk_to.

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 clearly implies this is for traveling by car rather than on foot, but it does not explicitly state when to use it over walk_to, exit_vehicle, or set_train_schedule. It gives the mechanism but no explicit when/when-not conditions or named alternatives.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the core move action but does not explain what happens when an equipment slot is already occupied, whether the operation can fail, what it does with existing equipment, or how to identify items (names vs IDs). These are meaningful gaps for a side-effecting mutation tool.

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 filler. It efficiently communicates the action, the items involved, and the source and destination slots.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity of three optional string parameters and the existence of an output schema, the description is serviceable. However, it omits important invocation details such as item identifier semantics, handling of occupied equipment slots, and failure behavior, making it incomplete for an agent trying to call the tool correctly 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?

Schema description coverage is 0%, but the description does add meaning by mapping gun, ammo, and armor to item types moved between inventory and equipment slots. It does not fully compensate for the lack of schema descriptions: it never states the expected value format (item name, ID, etc.) or the exact behavior when a parameter is null.

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: moving gun, ammo, and/or armor from the main inventory into equipment slots. It clearly differentiates this from sibling inventory tools like insert_items or check_inventory because it names the unique destination (equipment slots) and the specific item categories.

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 usage context is implied: the tool should be used when the agent wants to equip items into equipment slots. However, it does not explicitly name alternatives, say when not to use it, or describe prerequisites such as the item needing to exist in the main inventory.

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 merely restates the action without adding any details about preconditions (e.g., must be in a vehicle), side effects, or failure modes. No information is given about what happens if the agent is not in a vehicle or whether the action has any cost or delay.

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 directly states the action. It is appropriately minimal for a zero-parameter tool and contains no unnecessary words or 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?

Given the tool's simplicity (zero parameters, no annotations, output schema present), the description covers the essential purpose. It could slightly improve by explicitly stating the precondition of being inside a vehicle, but the phrase 'you are in' already implies this context. Overall, it is sufficient for an agent to understand when to call it.

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

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

The tool has zero parameters, so the schema fully covers all inputs. The description does not need to explain parameter semantics, and the baseline of 4 applies. No additional parameter context is required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('leave') and resource ('vehicle'), with a clear qualifying context ('you are in'). It is unambiguous and distinguishable from sibling tools like drive_to and walk_to, which involve moving toward or operating a vehicle.

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 implies usage: use this when you want to exit the vehicle you are currently in. However, it provides no explicit guidance on when not to use it or alternatives, though the simplicity of the tool makes this somewhat acceptable. It lacks any exclusions or conditionals.

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 (no readOnlyHint, destructiveHint), the description provides necessary behavioral context: it captures (reads) buildings, requires explored area, respects a size limit, and produces a specific output format (string with counts and anchor). While it doesn't mention side effects or permissions, the capture operation is non-destructive, and this is implicitly conveyed. There is no contradiction with annotations.

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, concise sentence that front-loads the core action and limits. Every word adds value, covering scope, size constraint, output type, and additional outputs (entity counts, anchor). It's efficient without being vague.

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?

High context: 5 parameters with 0% schema coverage, no annotations, but an output schema exists. The description provides essential context (rectangle, max size, output format) but leaves gaps like label semantics and exact coordinate handling. Given the output schema covers return values, this is relatively complete, but the label and coordinate details are missing.

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

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

Schema coverage is 0% (no descriptions in schema), and the description only explains the rectangle (x1,y1) to (x2,y2) but doesn't clarify the label parameter's purpose or how they map to coordinates. It also doesn't specify the meaning of the rectangle's bounds (inclusive? in tiles?) beyond the max size. This leaves the agent to guess about label usage and coordinate system.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (export), the resource (buildings in an explored rectangle), and key constraints (max 200x200 tiles) and outputs (blueprint string, entity counts, map anchor). It is specific and distinguishable from siblings like list_blueprints and import_blueprint, though it doesn't explicitly differentiate 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?

The description indicates this is for capturing buildings in an explored area, which is clear enough. It doesn't explicitly mention when not to use it or alternative tools, but the 'explored rectangle' constraint and mention of building capture imply a niche that isn't covered by 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?

Since no annotations are provided, the description carries the behavioral disclosure burden. It does reveal that the agent may walk within reach and that items are transferred into inventory, which is useful. However, it does not disclose whether the extraction is destructive, how queuing/jobs work, or what happens if the entity has insufficient items or the inventory is full.

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 one compact sentence with no wasted words. It front-loads the core operation, then adds the two selection modes and the movement note, all in a natural order that supports quick agent comprehension.

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 has 6 parameters and no annotations, and while the output schema exists, the description does not mention key behavioral context such as job queuing, wait_s/replace semantics, or possible side effects. The core invocation path is clear, but a fully informed agent would need to infer job-related behavior from parameter descriptions rather than from tool-level guidance.

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 67%, and the description adds meaningful semantics beyond the raw parameter definitions. It clarifies the relationship between the items parameter and all=true ('specific counts, or all=true'), which is not obvious from defaults alone. It also adds the agent movement behavior associated with the location parameters. wait_s and replace are already well documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: take items out of the entity at a coordinate and put them into the agent's inventory. It also distinguishes the tool from the sibling insert_items by the direction of transfer. However, it does not explicitly mention alternatives or name the most similar sibling, so it stops short of a perfect 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 description gives operational guidance: use specific counts or set all=true, and the agent may walk within reach. But it does not state when this tool should be used over alternatives such as mine, insert_items, or inspect_entity, nor does it mention exclusions. Usage context is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains the combat loop (walk, shoot, next target), the radius anchoring, and the flee_below retreat threshold. It omits edge cases like what happens when no enemies are found or if the player dies, but covers the core mechanics sufficiently.

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, well-structured sentence that front-loads the primary action and includes critical behavioral details without unnecessary words. Every clause contributes to understanding the tool's operation, making it highly concise and easy to parse.

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 that an output schema exists (likely defining job id and status) and the parameter descriptions cover wait_s and replace, the description provides adequate context for the core combat behavior. It does not mention prerequisites like needing a gun equipped (though implied) or failure conditions, but for a combat action with an output schema, it is reasonably 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 schema provides descriptions for only 2 of 6 parameters (wait_s and replace), giving 33% coverage. The description adds meaning for radius (anchored range) and flee_below (retreat threshold), but does not elaborate on x/y beyond 'around a point' or the interaction with wait_s/replace beyond what the schema already states. It partially compensates for the low schema coverage but not fully.

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 ('Fight') with a clear resource ('visible enemies around a point') and details the behavior ('walks into range, shoots, next target'). It also specifies anchoring to the radius and retreat behavior, making the purpose unmistakable. It distinguishes from siblings like 'defend_area' by focusing on active engagement rather than static defense.

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 implies usage—fight enemies within a radius using the equipped gun—but does not explicitly state when to choose this over alternatives such as 'defend_area' or other combat tools. There is no exclusionary guidance (e.g., 'use when you want to actively seek enemies' vs 'defend_area' for passive defense), leaving some ambiguity in tool selection.

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

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

With no annotations, the description carries the behavioral disclosure burden. It clearly reveals the search rules: free land excludes water/cliffs/entities, trees are allowed and counted, ground must be explored, and the result is the nearest match. It does not mention max_distance semantics or failure behavior, but the core behavior is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence front-loads the core function and all key constraints. Every clause adds semantic value; there is 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?

The description covers the search criteria and location anchor, but leaves max_distance unexplained and does not describe behavior when no area is found. The presence of an output schema offsets return-format gaps, so the definition is adequate but not fully comprehensive.

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. It explains width and height as rectangle dimensions and x/y as the nearby point, but max_distance is entirely undocumented in both the schema and description, leaving a fifth parameter without meaning.

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 ('find') and resource ('nearest width x height rectangle of free land') with explicit constraints: no water, cliffs, or entities; trees allowed and counted; explored ground near a point. This clearly distinguishes it from siblings like can_place and scan_area.

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 when a rectangular free area is needed near a point, but does not name alternatives or state exclusions. An agent can infer this is a search tool, but there is no explicit guidance about when to prefer it over can_place or scan_area.

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 behavioral burden. It discloses two important non-obvious traits: persistence and the fact that it replaces current jobs. It does not mention failure modes or null-player behavior, but core side effects are covered.

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 no wasted words. The persistence label is front-loadedhol and the job-replacement warning is stated immediately after the core behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description captures the essential purpose and the main side effect, and an output schema exists so return-value detail is not needed. However, the ambiguous nullable player parameter and lack of guidance on what happens with no arguments leave a meaningful gap for an agent invoking the 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 description coverage is 0%, and the description adds little beyond the parameter names. 'Follow a player at a distance' loosely maps player and distance to their roles, but it does not explain the nullable player default, distance bounds, or how the distance value is used.

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 at a distance until cancelled.' The phrase 'Persistent job' immediately distinguishes it from one-shot movement siblings like walk_to or drive_to.

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 clear invocation context: this is a persistent job that runs until cancelled and replaces current jobs. It does not explicitly name alternative tools or when-not-to-use, so it falls just short of full routing guidance.

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

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

No annotations are provided, so the description must disclose behavioral traits on its own. It mentions events 'since your last read,' which implies the tool tracks read state, but it does not explicitly state whether calling this tool updates that state or has other side effects. 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?

The description is a single sentence that front-loads the core purpose ('Events since your last read') and gives helpful examples. The parenthetical 'or since since_id' is slightly redundant but not wasteful. Overall it is concise and well-structured.

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 (one optional parameter) and has an output schema, so the description does not need to explain return values. However, it omits the critical behavioral detail about whether the 'last read' marker is updated, and it does not mention event ordering or pagination. For a tool with no annotations, this leaves the agent uncertain about side effects.

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 carries the burden of explaining since_id. It does explain that the parameter overrides the 'last read' baseline, providing some meaning beyond the schema. However, it does not clarify inclusivity/exclusivity of the ID or how to obtain a valid 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?

The description clearly states the tool retrieves events (jobs finishing/failing, combat, research, supply warnings) since a specified ID or last read. It identifies the resource and verb distinctly, but does not explicitly distinguish it from sibling tools like wait_for_events.

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 guidance on when to use this tool versus alternatives such as wait_for_events or status. It implies polling for events but does not state when this is appropriate or what the trade-offs are.

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 burden, and it directly addresses the most important behavioral concern: this tool 'Does not build,' so it is safe and non-destructive. It also adds concrete behavior by specifying the coordinate system (top-left entity at 0,0) and what data is returned. It does not cover failure modes or validation behavior, but for a decode operation this is minor.

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 entire description is two short, high-information sentences with no wasted words. The primary verb and resource are front-loaded, and the exclusion is placed at the end for emphasis.

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 description covers the core action, the input format, output categories, and the coordinate system, and an output schema exists to define the return structure. The main missing piece is the purpose of `limit`/`offset`, but for a straightforward decode tool the description is otherwise sufficient.

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 only parameter with any semantic grounding is `string`, which the description identifies as a blueprint export string; the required input's meaning is therefore clear. However, `limit` and `offset` are not mentioned at all, and with 0% schema description coverage there is no other source explaining these pagination parameters.

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 operation ('Decode'), a specific input ('blueprint export string'), and enumerates the decoded content (entity positions, directions, recipes, item bill). It also states the coordinate origin behavior and explicitly separates itself from build actions, so an agent can distinguish it from build_blueprint and export_blueprint.

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 clearly marks the tool as not building, giving an explicit exclusion for construction use cases. It does not explicitly name sibling alternatives such as build_blueprint or export_blueprint, but the decode-vs-build contrast provides sufficient context for selecting this tool for analysis rather than creation.

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, but it only mentions walking. It does not disclose that this is likely a job-queueing operation (evident from wait_s and replace), that it can block until completion, that it may return a job id, or that it can cancel existing jobs when replace is used. The mutation of inventory is clear from 'Move', but the consequential job semantics are omitted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It communicates the core action and destination immediately. The parenthetical '(walks within reach)' is compact but slightly ambiguous, which keeps it from a perfect 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given five parameters, an output schema, no annotations, and many siblings, the description is under-specified. It fails to mention that the operation can take time, queue behind other jobs, or return a job id, and it does not clarify what kinds of entities are valid targets. The schema partially compensates for wait_s and replace, but the overall context is too thin for safe autonomous use.

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

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

Schema description coverage is 100%, and the schema already fully documents x, y, items, wait_s, and replace, including item syntax and wait/replace behavior. The description adds no new parameter-level meaning, so the baseline 3 is appropriate. It does not harm, but it does not compensate beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Move'), the source ('items from your inventory'), and the destination ('into the entity at x,y'). This unambiguously distinguishes the tool from its sibling extract_items (the reverse operation) and from craft_items, which creates new items. The parenthetical also communicates a key operational trait: the agent may need to walk to reach the 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?

The description implies the tool is for depositing inventory items into an entity, but it never explicitly explains when to choose insert_items over alternatives like extract_items or craft_items. There is no 'use when' or 'instead of' guidance, and the reach/walking condition is only implicit. Agents must infer the intended usage from the tool name and sibling 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently describes important scope limitations: searched within 1.5 tiles, explored ground only, other forces only while visible, and up to 16 entities per call. While it does not explicitly state that the call has no side effects, the read-oriented nature and detailed data list make that reasonably clear.

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, dense sentence that front-loads the core purpose ('Details of entities near map positions') and then packs necessary constraints into parentheticals. It is not bloated, though a slightly more structured layout could improve readability. Every clause contributes useful 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?

The description covers the search behavior and result contents well, and the presence of an output schema reduces the need to explain return values. However, it leaves ambiguity around the input contract: all three parameters are optional and there is no explanation of how x/y vs. targets are used, which could cause incorrect calls.

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 only 33%, so the description must compensate for undocumented x and y parameters. It adds context about map positions, the search radius, and batch limits, but it does not clarify how x/y relate to the targets array, whether they can be combined, or what happens if no position is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns details of entities near map positions and enumerates the specific fields returned (type, status, recipe, inventories, etc.). It is specific enough to distinguish from general-purpose siblings like status or look_around, though it does not explicitly name any alternative.

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 useful contextual constraints (1.5 tile search radius, explored ground only, other forces only while visible, max 16 per call), which imply when it is appropriate to call. However, it does not explicitly tell the agent when to prefer this over siblings like scan_area or analyze_factory, nor does it state when not to use it.

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. It adds the useful effect 'stopping your character' and explains the all=true variant. However, it does not describe what happens if both all=false and job_id are null, whether cancellation is reversible, or any error conditions.

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 efficient sentence with no filler. The main action and the key parameter behavior (all=true) are front-loaded, and 'stopping your character' adds relevant consequence without bloating the 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 two-parameter tool with an output schema, the description covers the core behavior and the main variant. Still, it does not specify the default behavior when no job_id is given and all=false, or how the tool relates to the current job versus queued jobs. These gaps make it minimally adequate rather than fully 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%, so the description must compensate. It does explain that all=true cancels all jobs and that otherwise one job is canceled, which gives meaning to the boolean. However, it never names job_id, its type, or the meaning of null/defaults, leaving part of the parameter surface under-specified.

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 ('Cancel'), identifies the exact resource ('your jobs'), and adds scope ('one of them, or all of them'). It clearly distinguishes itself from siblings like job_status and job_wait, which are for checking state rather than canceling.

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 explains the operation but gives no guidance on when to choose job_cancel instead of job_status or job_wait)Skip this. It does not state prerequisites, context, or exclusions. Usage is only implied by the word 'cancel' rather than explicitly differentiated.

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 burden of behavioral disclosure. It usefully reveals that omitting job_id returns the running job, queue, and recently finished jobs, but it does not mention error handling, return format, or explicitly state that this is a read-only operation. It is adequate but not richly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, dense sentence states the core behavior and the optional-parameter branch without wasted words. The most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, one optional parameter, and the presence of an output schema, the description covers the main calling patterns. Minor gaps such as what happens with an invalid job_id or how 'recently finished' is defined are left unstated, but the core usage is complete.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented job_id parameter. It does so by explaining the behavioral difference between providing and omitting job_id, which is the essential semantic. It does not restate the integer type, but the name and behavior make it reasonably clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (jobs) and the two modes: status of a specific job with job_id, or running/queued/recent jobs without it. It lacks an explicit verb like 'Get' or 'Retrieve', so it does not fully meet the 5-level bar, but the purpose 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?

The description gives clear context for when to include job_id versus omit it, which is the key usage decision for this tool. It does not explicitly compare against sibling tools like 'status' or 'job_cancel', but the calling-mode guidance is clear enough.

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 only states that it waits up to a timeout, but does not reveal what happens on timeout (error vs. return), whether the call is safe to repeat, or if it immediately returns when the job is already finished. These are significant gaps for a blocking operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no filler or redundant detail. It is front-loaded and efficiently conveys the tool's purpose in the fewest possible 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?

Given the tool has two parameters, no annotations, and only a basic description, it lacks critical behavioral and boundary details. The existence of an output schema helps return-value understanding, but the description still fails to explain timeout behavior, edge cases, or prerequisites, leaving an agent uncertain about invocation semantics.

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 for parameter meaning. It adds some context for timeout_s by explaining its role in the wait, but it does not explain that job_id identifies the specific job to wait for beyond the implicit 'your jobs'. The description adds minimal semantic value over the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Wait up to timeout_s') and a clear resource ('one of your jobs to finish'). It effectively communicates the tool's core function. However, it does not explicitly distinguish it from siblings like job_status or wait_for_events, so it falls just 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 description gives no guidance on when to use this tool versus alternatives. It does not mention that this is for blocking until completion rather than polling status, nor does it reference any conditions for using job_cancel or job_status. The usage context is entirely left 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?

With no annotations, the description carries the full behavioral burden. It does disclose key traits: the job persists until cancelled, consumes fuel from inventory, and replaces existing jobs. However, it leaves out failure modes, behavior when inventory is empty, and whether anything is lost when replacing jobs.

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 concise sentence, front-loaded with 'Persistent job' and containing no filler. Both the core purpose and the important side effect are included efficiently.

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 job tool with four parameters, zero required, and three nullable with no schema descriptions, the description leaves important gaps: what omitted x/y/fuel mean, how to stop the job, and what happens on fuel shortage. An output schema may explain return values, but invocation semantics remain under-specified.

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 has 0% description coverage and no parameter descriptions. The description adds meaning by associating 'around a point' with x/y/radius and 'from your inventory' with the fuel parameter. It does not clarify the null defaults for x, y, and fuel, nor radius units or inclusivity.

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 continuous behavior ('keep burner machines around a point fuelled from your inventory until cancelled') and identifies it as a persistent job that replaces current jobs. It is clear and actionable, but it does not explicitly contrast with sibling job tools like job_cancel or job_status.

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 guidance or alternative routing is provided. 'Until cancelled' and 'replaces your current jobs' imply job semantics, but there is no mention of when to prefer this over insert_items, build_plan, or job_cancel, nor any prerequisites or cancellation instructions.

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 behavioral burden. It usefully discloses that nested books are included, but it does not explicitly state that the operation is read-only or describe any side effects. For a list operation this is acceptable, though not thorough.

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. The scope detail is front-loaded, though the phrasing is slightly elliptical ('Blueprints your character carries' lacks an explicit verb).

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 parameterless list operation with an output schema, the description adequately captures the return scope (inventory, books, nested books). It does not clarify whether other carried locations like hands are included, but this is a minor gap given the tool's simplicity.

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 coverage is 100% (vacuously). The description adds no parameter-level detail, but none is needed since there is nothing to document.

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 identifies a specific operation (listing the character's carried blueprints) and clearly scopes it to inventory and books, including nested books. It is distinguishable from siblings like read_blueprint or build_blueprint, though it lacks an explicit verb and does not name alternative tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as check_inventory or read_blueprint. The description implies a lookup use case but gives no exclusions, prerequisites, or scenario 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 behavioral disclosure burden. It communicates a read-only listing scoped to the current surface and notes that train stop names are included, but it does not explicitly state that no mutation occurs or describe the result format. For a simple list tool this is adequate but not deeply transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single compact sentence with a dense field list and no filler. The telegraphic phrasing is slightly awkward, but every word contributes useful 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 the zero-parameter schema and the existence of an output schema, the description is mostly complete: it states the surface scope and the fields returned. It lacks a when-to-use note, but the agent can likely invoke it correctly without more information.

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

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

The input schema has zero properties, so there are no parameter semantics to document. The description adds no parameter information, which is appropriate for a zero-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource ('trains'), the scope ('on your surface'), and the exact fields returned, so the purpose is clear despite missing an explicit verb. It does not explicitly differentiate from related siblings like set_train_schedule, but the name 'list_trains' plus the field list make the operation 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 about when to use this tool versus alternatives such as set_train_schedule or status. The intended use case must be inferred entirely from the tool name and the enumerated fields.

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. It usefully notes that information is limited to explored ground and visible entities, implying spatial awareness constraints. However, it never explicitly states that the call is non-mutating or whether the radius affects all returned data.

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 dense sentence with no filler, and it front-loads the character state before listing environmental details. It is somewhat run-on as a catalog, but every clause contributes useful 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 that an output schema exists and the tool has only one optional parameter, the description captures the main content categories and visibility/exploration constraints. It lacks explicit read-only signaling and usage context, but these are already penalized in other dimensions, and the provided information is sufficient for basic invocation.

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

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

Schema coverage is 100% for the single radius parameter, which already has a description and default value. The description adds no extra meaning about how radius interacts with the observation scope, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool returns: character position, inventory, equipment, jobs, visible entities, resources, buildings, enemies, research, power, and production. It is specific about the resource and scope, though it does not explicitly contrast it with sibling tools like status, check_inventory, or scan_area.

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 look_around versus alternatives such as status, check_inventory, or scan_area. The agent must infer usage from the listed fields; no exclusions, prerequisites, or alternative routing is provided.

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 behavioral burden and does meaningful work: it discloses vanilla mining time/reach, the 80-tile explored-ground limit, count-based operation semantics, and the supported resource-name patterns. It does not mention job queuing or cancellation behavior, though replace/wait_s are documented in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The entire key behavior is packed into one dense front-loaded sentence with no filler. It is slightly long and parenthetical-heavy, but every clause carries useful constraint or mode 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 6-parameter tool with no annotations, the description covers the core modes, range, timing model, and resource examples. An output schema exists, so return values need not be explained. It could be more explicit about what happens if both x/y and resource are supplied, but "either...or" largely covers this.

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 only 33%, but the description compensates by explaining x/y (minable thing at a coordinate), count (number of mining operations), and resource (named resource like "iron-ore" or "tree"). The remaining two params, wait_s and replace, already have explicit schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a clear verb and resource: "Mine by hand" with two explicit modes (targeted x,y mining or named-resource mining by count) and concrete constraints (vanilla mining time/reach, explored ground, 80 tiles). This makes it easy to distinguish from sibling tools like deconstruct or place_entity.

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 clearly implies when to use the tool: when manually mining either a specific tile or a resource within range. However, it never explicitly states when not to use it or names alternative tools such as deconstruct or build_plan, leaving some routing to the agent's 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?

With no annotations, the description carries the behavioral disclosure burden. It does disclose two useful behaviors: the player may walk to reach build range, and normal placement rules apply. However, it does not state that placement is likely a queued/running job (implied by wait_s and replace), what happens on invalid placement, or whether the item is consumed. This is adequate but incomplete.

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 a parenthetical clarifier; there is no filler or repeated schema information. The primary action and the most important behavioral caveat are both front-loaded. Every part of the sentence contributes useful 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?

The definition is sufficient for a basic invocation given the rich input schema and the presence of an output schema. However, it leaves some selection context implicit: it does not mention when to prefer can_place for checking placement, nor does it clarify the job-queue semantics beyond the parameter descriptions. For a 6-parameter action tool, that is a moderate 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 coverage is 67%, and most parameters already have descriptions in the schema. The description adds value by explaining item as 'from your inventory' and implying that x/y may be outside the player's current build range because the tool walks. It does not add meaning for direction, wait_s, or replace, but those are already documented in the input 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 uses a specific verb-resource pair: 'Place a building from your inventory'. The parenthetical 'walks within build range; normal placement rules' adds behavioral specificity and helps distinguish this from blueprint-based tools like build_blueprint. It clearly tells an agent what action and target this tool operates on.

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 clear use context: call this when you want to place a building from inventory, and it explicitly says the tool will walk to be within build range. It does not explicitly name exclusions or alternatives such as can_place for validation or build_blueprint for blueprint placement, so it is 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, the description carries the full burden and does a decent job: it clarifies that results are force-specific, surface-specific, time-windowed, and include all-time totals. It does not explicitly state whether the operation is read-only, but the content strongly implies a non-mutating statistics query.

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 focused sentence that front-loads the most important information: what is measured, for whom, where, and over what kind of time range. There is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and the input schema carries defaults and enums, the description is largely sufficient for an agent to understand what the tool returns and how it is scoped. Minor gaps remain around ordering/limiting behavior, but these do not block correct invocation.

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 only 25%, and the description partially compensates by tying the metric to the 'window' and 'kind' parameters. However, it adds little meaning for 'top' or 'names', leaving the agent to rely mostly on parameter names and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource and metric: item and fluid production/consumption for the player's force on their surface, with per-minute rates and all-time totals. It is specific enough to distinguish from inventory or status tools, though it lacks an explicit verb and does not name a sibling alternative.

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 clear context for when to use the tool: whenever production/consumption statistics for items or fluids are needed over a time window. It does not explicitly discuss alternatives or exclusions, but the scope is clear enough that an agent can infer appropriate use.

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. 'Decode' and 'read' imply a non-mutating operation, and 'in windows' hints at pagination, but there is no explicit statement about side effects, prerequisites (e.g., blueprint must be carried), or permission needs. This is adequate 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?

The description is a single, efficient sentence that front-loads the core action ('Decode a carried blueprint by label') and then specifies the output. There is no fluff 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?

An output schema exists, so return format is not needed. However, the description does not clarify what constitutes a 'carried blueprint', what 'relative entity positions' and 'item bill' mean, or what happens if the label is not found. Given the tool's moderate complexity and zero annotations, more context would help the agent 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. It mentions 'by label' (covering the label parameter) and 'read in windows' (covering limit/offset), but the 'book' parameter is entirely unaddressed. The description adds minimal value beyond the schema and does not fully explain all parameters, leaving the agent to guess at book's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'decode' and the resource 'carried blueprint by label', and specifies the output: relative entity positions and item bill. This differentiates it from siblings like list_blueprints (listing) and build_blueprint (building), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus alternatives like list_blueprints or import_blueprint. The phrase 'by label' implies a specific blueprint is targeted, and 'read in windows' suggests pagination, but no exclusions or alternative conditions are given. The usage context is inferred 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose important behavior: messages are returned since the last read or since an explicit since_id, and the caller's own lines are excluded. However, it does not clarify whether reading advances the server-side 'last read' cursor, whether there is pagination, or whether any authentication or stateful side effects apply.

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 compact sentence that front-loads the core behavior and adds the key scope exclusions efficiently. Every phrase adds value; there is no filler or redundant restating 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 simple one-parameter read operation with an output schema present, the description covers the main facts an agent needs: what is returned, the cursor semantics, and whose messages are included. The only notable gap is the unclear side effect on the 'last read' marker, which matters for repeated polling but does not greatly reduce usability.

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 for parameter documentation. The parenthetical 'or since since_id' does explain the parameter's role, and the parameter name plus schema type are fairly self-explanatory. However, the description does not clarify the distinction between null (use last-read cursor) and an integer (use explicit position), leaving some work to the agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (chat messages) and the operation's scope: messages since a cursor, from players and other agents, excluding the caller's own lines. It is not fully a verb+resource phrasing ('Chat messages since...' rather than 'Read chat messages...'), but the title disambiguates the action. It implicitly distinguishes from 'say' by focusing on reading and excluding own lines.

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 explicit guidance on when to use this tool versus alternatives like 'say' or 'get_events'. It describes the behavior but not the context or conditions under which an agent should call it. There is no mention of when not to use it or what makes it the right choice.

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 transparently discloses that this creates a new body at the spawn point and applies the scenario's respawn kit, but it does not mention potential side effects such as item loss, kit consumption, or state resets. This is a moderate gap for a state-changing tool.

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, efficient sentence with no filler. It front-loads the core action ('Create a new body'), then adds the location, trigger, and kit information in a compact way.

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 and an output schema present, the description covers what an agent needs to invoke the tool correctly: the action, the condition for use, and the result location. It does not explain deeper consequences, but for a zero-argument tool that is not a critical omission.

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

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

The tool has zero parameters, so the input schema already covers everything. The description is not required to explain parameter details, and it does not contradict the schema. The baseline of 4 for a no-parameter tool 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?

The description uses a specific verb ('Create'), names the resource ('a new body for your character'), and specifies the location ('at the spawn point') and trigger ('after death'). This clearly distinguishes respawn from the many sibling tools, none of which perform this action.

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)' explicitly indicates when the tool should be used, providing clear contextual guidance. It does not mention when not to use it or compare against alternatives, but with no sibling performing an equivalent respawn action, the situational cue is sufficient.

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 useful behavioral trait: the agent will walk within reach to perform the rotation. However, it does not describe job queueing/wait behavior, failure conditions, reversibility, or other side effects beyond the rotation itself.

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 filler. It conveys the action, target, operation modes, and a behavioral note in a compact form, earning every word.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter tool with an output schema and 80% schema coverage, the description is minimally sufficient but leaves ambiguities: what 'one step' means, when to choose this tool over siblings, and how wait_s/replace interact with the rotation job. It is usable but not fully self-sufficient.

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 80%, so wait_s and replace are already documented in the schema. The description adds meaning by clarifying that omitting direction corresponds to a 'one step' rotation, which the schema does not state. It also connects the direction parameter to the rotation concept, though the schema provides the explicit north/east/south/west mapping.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (rotate) and a specific target (entity at x,y), and clarifies two operation modes: one-step rotation or explicit 16-way direction. The verb is unique among the listed sibling tools, so the agent can distinguish it from inspect_entity, place_entity, deconstruct, etc., though it does not explicitly name an alternative.

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 rotate_entity versus other entity-related tools, nor any mention of prerequisites or when not to use it. The parenthetical 'walks within reach' hints at distance behavior, but it does not explain when the tool should be selected over alternatives.

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

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

With no annotations, the description carries the full burden. It discloses the critical failure behavior (cancellation of the rest of the chain if one fails) and the waiting behavior (up to wait_s). This is valuable beyond what the schema provides. However, it does not mention permissions, reversibility, or return format, though the output schema likely covers the latter.

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 two sentences with zero fluff. It front-loads the core action (queue a sequence of actions), lists the action types, and includes the most important behavioral nuance (chain cancellation) in a compact form.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the existence of an output schema, the description covers the key behavioral aspects: chaining, cancellation on failure, and waiting. It does not explicitly mention that it can replace multiple individual calls, but the sibling list makes that inference straightforward. The schema fills remaining parameter details, so the description is sufficiently 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 coverage is 67% with descriptions for wait_s and replace. The tool description adds minimal parameter-specific detail—it only references wait_s implicitly and does not elaborate on steps beyond listing action types. The schema already documents PlanStep properties thoroughly, so the description adds little over the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool queues a sequence of actions, explicitly listing the action types (craft, insert, extract, mine, place, set_recipe, rotate, walk_to). This distinguishes it from single-action siblings like craft_items or extract_items, and the phrase 'chained jobs' conveys the batch nature.

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 mentions waiting behavior but does not explicitly state when to use this tool versus individual action tools or when not to use it. The purpose implies batching, but no alternatives or exclusions are named. The schema descriptions for wait_s and replace add some context, but the description itself provides no direct usage guidance.

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

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

With no annotations, the description is the sole source of behavioral information. It discloses the core side effect (an in-character message in game chat), but does not state whether the message is publicly broadcast, whether permissions or cooldowns apply, or what the tool returns.

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 filler; every word contributes meaning, and the roleplay context is embedded without extra clauses.

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 command with an output schema and a straightforward action, the description plus input schema is sufficient for correct invocation. It lacks explicit when-not-to-use guidance and richer behavioral detail, but the operation is simple enough that these are minor 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 only parameter, text, is self-explanatory as the message content, and the description's 'something' maps to it. However, schema description coverage is 0%, and the description does not add detail beyond that mapping or mention the length constraints, though the schema itself carries them.

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 ('say') tied to a clear resource ('game chat') and adds the roleplay constraint 'as your character.' This makes it immediately distinguishable from sibling tools like read_chat and other non-chat actions.

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 'Say something in game chat as your character' gives a clear context for use: when the agent's character needs to speak in chat. It does not explicitly name read_chat as the alternative for reading, but the action is self-evident and there are no competing write-chat 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?

With no annotations, the description carries the full burden and mostly succeeds: it discloses row order (north to south), unexplored-tile representation ('?'), and symbol meanings (uppercase, lowercase, @). It doesn't state whether the operation is purely read-only, but the passive 'scan' framing and emphasis on output format cover the most important 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 with no filler, front-loading the core output ('ASCII tile grid of a square area') and then adding distinct facts: orientation, unexplored marker, and legend. Every sentence 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?

The output format and legend are well covered, and an output schema exists so return values don't need explanation. However, the description leaves x/y semantics and the geometric relationship between radius and grid size unexplained, and offers no comparison to observation siblings, so an agent may still guess at input meaning.

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

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

Schema coverage is only 33% (only radius is described), and the description adds no meaning for x or y: whether they are coordinates, whether null means 'current position', or how they relate to the square area. The description also doesn't reinforce the radius half-width relationship beyond what the schema already says.

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 defines a concrete output: an ASCII tile grid with one character per tile, row orientation, and symbol legend, making the tool's function clear. It doesn't use an explicit verb like 'scan' in the description and doesn't explicitly distinguish itself from look_around, but the output format is distinctive enough to identify its purpose.

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 scan_area versus look_around, find_buildable_area, or other observation tools. The description only explains what the output looks like, not the situations that call for it or when a sibling would be preferred.

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 behavioral burden. It does disclose one important side effect—'walks within reach'—which is useful and not found in the schema. However, it does not mention queueing behavior, cancellation, or failure modes related to unreachable positions.

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 filler. It immediately states the action and target, then adds the movement caveat. Every word 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?

An output schema exists and the input schema documents most parameters, so the description need not repeat those. Still, the recipe parameter is only typed as a string with no guidance on accepted values or how to discover them, and the absence of usage guidance leaves the agent to infer the full 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 80%, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides: x and y are described in the schema, and recipe/wait_s/replace are not elaborated in 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 clearly states a specific verb ('Set'), resource ('recipe of the crafting machine'), and location ('at x,y'). It is self-explanatory and distinguishable from siblings like craft_items or inspect_entity, though it does not explicitly name an alternative.

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 guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The parenthetical 'walks within reach' hints at movement constraints, but it does not tell the agent when to prefer set_recipe over other crafting-related 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 burden. It discloses that the tool switches the train to automatic mode, which is a meaningful side effect beyond just setting a schedule. However, it does not mention whether this overwrites an existing schedule, whether it requires the train to be stopped, or what happens to the train's current route.

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 that conveys the core action and the key side effect. It is concise and every phrase earns its place, though it could add a brief note about overwriting behavior without becoming verbose.

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 has an output schema and only 2 parameters, so the description doesn't need to explain return values. It covers the main action and the automatic-mode side effect, but for a state-changing tool with no annotations, it should also disclose overwrite behavior and any prerequisites (e.g., train must exist, stops must already be discovered).

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. It explains that stops are 'existing stop names (case matters)' and mentions wait conditions, which adds meaning beyond the raw schema. However, it does not explain the wait value format (full/empty/seconds) or the train_id semantics, leaving the agent to infer from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Set') and resource ('a train's schedule'), and clarifies that it uses existing stop names with wait conditions and switches the train to automatic. It is clear enough to distinguish from list_trains and other train-related tools, though it doesn't explicitly name a sibling alternative.

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 implies when to use it: when you want to configure a train's schedule and enable automatic operation. It does not state when not to use it or mention alternatives like list_trains for inspecting schedules, but the context is reasonably clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'queue' which implies an asynchronous action, but it doesn't explain whether the research starts immediately, whether it can be canceled (though 'job_cancel' exists as a sibling), whether it consumes resources, or what the response looks like. The description adds minimal behavioral context beyond the verb itself.

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 concise sentence with no wasted words. It front-loads the action ('Queue') and the object ('a technology'). However, it's so brief that it sacrifices useful detail, so it earns a 4 rather than a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one required parameter, no annotations, and no parameter documentation, the description is too thin. It doesn't explain how to specify the technology, what happens after queueing, or how this relates to the broader research workflow. The output schema exists but the description doesn't set expectations for what the tool returns. A more complete description would cover prerequisites and follow-up actions.

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 for the single 'technology' parameter. The description mentions 'a technology' but doesn't clarify what format the technology string should take (e.g., exact name, ID, display name), where to find valid values, or whether it's case-sensitive. This is a meaningful gap for a single-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Queue a technology for research for your force' states a specific verb ('queue') and resource ('technology'), and the context of 'for your force' adds some scope. However, it doesn't distinguish this from sibling tools like 'set_recipe' or 'craft_items' that also involve queueing or production actions, and the phrase 'for your force' is somewhat vague about what that means in practice.

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 explicit guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., having a research lab, enough resources), nor does it contrast with related tools like 'set_recipe' or 'craft_items'. The only implied usage is that it's for research-related actions, but no exclusions or alternative conditions are provided.

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 does disclose one genuine behavioral trait — a potential connection-establishment side effect ('Connect (if needed)') — which is useful, but discloses nothing else about side effects, safety, or failure modes. Partial but honest disclosure.

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 tight, front-loaded sentence where every clause earns its place: the conditional connection side effect and the three report components. No filler, no repetition of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with an output schema present, the description supplies the essential call context: what may happen (connection) and what is reported. The only real gap is the lack of routing guidance against surrounding-focused siblings, 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?

The tool has zero parameters, which earns a baseline of 4 under the rubric. Schema coverage is trivially 100% and there is no argument meaning for the description to elaborate on.

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 verb ('report') and a specific scope: connection state, character binding, and surroundings summary. It implicitly differentiates from siblings like look_around and check_inventory by bundling these three signals into one composite status view, 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?

Usage is implied: call this when you need a composite situation/status summary before acting. It does not explicitly say when to prefer this over look_around or scan_area for surroundings, nor does it state when not to use it, leaving routing to agent 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?

With no annotations provided, the description carries the behavioral disclosure burden. It discloses the blocking nature, the timeout condition, and the polling frequency of about twice per second, which are useful operational details.

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 focused sentence that front-loads the blocking behavior and includes the essential operation details without any filler. Every part contributes to understanding the tool.

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 with one parameter and the description covers its behavior, wait condition, and polling cadence. Since an output schema exists, return-value details are not required in the description.

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

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

Schema description coverage is 0%, so the description must clarify the parameter. It does so by explaining that timeout_s is the wait limit after which the tool returns, adding functional meaning beyond the schema's type and constraints.

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 behavior: block until new chat or event arrives, or timeout passes. This clearly distinguishes it from non-blocking siblings like read_chat and get_events.

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 clearly implies that this tool is for waiting until new data arrives, but it does not explicitly say when to prefer it over alternatives like get_events or read_chat. The usage context is implied rather than 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?

No annotations are provided, so the description carries the full burden. It usefully discloses pathfinding behavior, normal walking speed, and the exploration-radius constraint. However, it omits the async job/queue semantics implied by wait_s, replace, and job-related siblings, leaving a significant behavioral 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?

The description is a single tight sentence with no filler. It front-loads the core action and the most important constraint, making it easy to scan and act on.

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 output schema exists, so return-value details are not required. Given the simple movement purpose, the description plus schema cover the essential invocation details, though job/queue behavior is only implied through parameters rather than explained in the tool description.

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

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

Schema coverage is high (4 of 5 parameters documented), so the baseline is 3. The description adds no parameter-specific meaning beyond the schema, and the undocumented arrive_within parameter is not clarified by the description either.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Walk to a map position') with a resource and method ('game pathfinder at normal walking speed'). It is distinct from obvious siblings like drive_to, but it does not explicitly name or contrast any sibling tool, so it stops short of full differentiation.

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 a clear precondition: the goal must be on explored ground or within the exploration radius. This implies when walk_to is appropriate, but it never states exclusions or alternatives, such as using drive_to for distant or unreachable targets.

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