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

With no annotations supplied, the description carries the full burden and does well: it discloses that the output is ghosts rather than real entities, that supplied construction robots can immediately build them, that existing buildings are not deconstructed, and that construction consumes the factory's normal materials. It omits failure behavior and whether repeated application is idempotent.

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?

Four short sentences, front-loaded with the core action, then the authorization gate, then the two side-effect clarifications. Each sentence adds information; 'Supplied construction robots' is slightly ambiguous about who supplies them, but no wording is wasted.

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

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

An output schema exists, so return values need not be described, and the behavioral side effects of ghost placement are well covered. However, for a two-required-parameter execution tool with zero schema descriptions and no annotations, the missing explanation of plan_id's provenance and lifecycle leaves a real gap.

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

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

Schema description coverage is 0% and neither parameter is mentioned in the description. The 'mode' parameter is partly self-documenting via its const value 'ghosts', but 'plan_id' — where it comes from (presumably create_plan) and what it identifies — is completely unexplained in both schema and prose.

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

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

The description opens with a concrete verb+resource: placing a plan as 'native ghosts', which distinguishes it from create_plan/preview_plan/inspect_plan by making clear this is the execution step. It doesn't explicitly name the sibling alternatives, so an agent must infer the boundary from the plan-tool family naming.

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?

'Use only when the assigned task authorizes placing ghosts' is an explicit gating condition, and 'Normal placement does not force deconstruction' clarifies that this is non-destructive relative to alternatives. It stops short of naming which sibling to use instead (e.g. place_entity for real entities), leaving that inference to the agent.

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 does disclose one important trait: 'Original library records are never modified', establishing a read-only safety profile. It adds nothing about pagination behavior, how recursion interacts with refs, or expected cost/size of results, so mutation semantics are the only behavior clarified.

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

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

It is short and front-loaded, with the browse scope first and the safety guarantee last, so size is fine. However, sentences like 'Browse player/game libraries, nested books, inventory and captured blueprints' are packed and cryptic rather than crisp, and 'RAILS' in capitals is unexplained noise.

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

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

A five-parameter, unannotated catalog tool needs at least a word on pagination and recursion semantics, and neither is present. The output schema covers return values and the read-only guarantee is stated, but the parameter space remains a black box for an agent deciding how 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?

Schema description coverage is 0% for five parameters, so the description must compensate and largely does not. It hints that 'query' searches RAILS or a project label and that 'ref' refers to returned references identifying exact records, but limit, offset, and recursive are entirely unexplained.

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 says it browses 'player/game libraries, nested books, inventory and captured blueprints', which gives a verb and a resource set, but the list is a grab-bag of overlapping concepts and 'RAILS' appears with no definition. An agent cannot cleanly separate it from siblings like inspect_blueprint or list_prototypes without opening the schema.

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

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

The only routing hint is 'Search RAILS or a project label with query', which tells how to use one parameter but not when to pick this tool over inspect_blueprint or list_prototypes. No exclusions, prerequisites, or alternative-tool guidance are given.

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

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

With no annotations, the description carries the full behavioral burden. It does usefully disclose a refund of crafting ingredients, but it omits whether the cancel is immediate or queued, whether partial progress is lost, which action categories are cancellable, and whether it errors when idle — significant gaps for a state-mutating control 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?

One sentence, front-loaded with the primary verb and terminating in the notable side effect. No filler or redundant restatement of the 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?

Return values are covered by the existing output schema, so the description needn't describe them, and a zero-param tool has little else to specify. The remaining gap is the absence of any state or failure behavior, which matters slightly more here since no annotations supply 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 takes zero parameters, so there is nothing for the description to disambiguate; the schema is empty and fully described. Baseline 4 applies.

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

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

"Stop the AI character and cancel its current action" gives a specific verb (stop/cancel) plus the resource (the AI character's in-flight action), and mentions the side effect of returning crafting ingredients. It is clearly distinguishable from siblings like get_action_status or craft, though it never names a sibling 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 it when an action is in progress and you want to abort it. There is no explicit guidance on what happens if no action is running, whether it works for every action type (mining, moving, shooting, crafting), or which sibling to consult first to confirm an action exists.

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

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

With no annotations, the description must carry the behavioral burden, but it only conveys snapshot-like capture and vaguely references native blueprint settings. It does not clarify whether a catalog entry or other persistent artifact is created, what capturing sandbox surfaces entails, or whether anything in the world is modified.

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

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

The single sentence is front-loaded and contains no filler. Its compression comes at the cost of leaving terms such as 'native blueprint settings' and important invocation details unexplained.

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 reduces the need to document return values, but correct invocation still depends on two undocumented required parameters, including an open-ended nested object. Given five parameters, no annotations, and several related blueprint siblings, the description is not complete enough to reliably guide selection and 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 0%, and the description does not explain the required surface identifier or the nested area object's expected shape and coordinates. Mentions of sandbox surfaces and native settings offer only weak hints and do not define label, include_tiles, or include_trains behavior.

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

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

The description gives a clear verb and resource—capturing a layout as a blueprint—and adds the notable capability of supporting sandbox surfaces. It does not explicitly distinguish this operation from siblings such as import_blueprint, export_blueprint, or create_plan.

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 wording implies use when taking a native-settings blueprint snapshot, including on sandbox surfaces. However, it gives no explicit conditions, prerequisites, or guidance on when to choose this over the other blueprint or planning 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 behavioral burden and delivers almost nothing: it does not say whether configuration is partial or full-replace, whether it is destructive or reversible, what permissions or entity state are required, or what 'native entity methods' means for the caller. It does at least signal a mutation of an existing nearby entity.

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

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

One short sentence with no filler, which is structurally clean. But the brevity reflects under-specification rather than economy: nothing is front-loaded beyond the verb, and no clarifying detail follows.

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

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

This is a complex, 9-parameter mutation tool with no annotations and no parameter documentation; the presence of an output schema only removes the need to describe return values. The description leaves the parameter semantics and behavioral contract entirely unaddressed, which is not adequate for this complexity.

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?

Nine parameters with 0% schema description coverage, and the description mentions none of them. Fields like 'recipe', 'surface', 'direction', 'unit_number', 'station_name' and 'control_parameters' have no explanation anywhere, so the agent has no basis for choosing values or understanding which fields apply to which entity type.

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

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

Names a specific verb ('Configure') and a resource class ('a nearby machine, station or control behavior'), which is more than a tautology. However, 'configure' is broad and 'control behavior' is undefined, so the agent cannot tell precisely what operation this performs versus siblings like place_entity or inspect_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 only contextual hint is 'nearby', implying a proximity constraint. There is no statement of when to use this versus place_entity (create), inspect_entity (read), or execute_lua (arbitrary scripting), and no prerequisites or exclusions.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: the craft consumes real ingredients and advances game time (i.e., it is not instantaneous). Mentioning an action ID implies an asynchronous queue, but it never says to poll get_action_status or that cancel_action can abort it, and says nothing about failure modes or permissions.

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

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

Two short sentences, front-loaded with the action and followed by the return contract, with zero padding. It is efficient, though the brevity is part of why semantics are under-specified.

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 values need not be spelled out, but for a mutation-like queue operation with no annotations and 0% parameter coverage the description is too thin. Recipe format and quality semantics are the biggest unanswered questions an agent would need before calling 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% across three parameters. The description never explains what form `recipe` takes (prototype name string? object?), what `quality` means or that null is the default, or how `count` interacts with ingredient consumption. None of the meaning missing from the schema is supplied.

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

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

The description gives a specific verb plus resource ("queue hand crafting") and distinguishes it implicitly from machine-based production by specifying hand crafting. An agent can tell what it does at a glance, though it never names a sibling such as list_recipes (for recipe identifiers) or configure_entity (for machine 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?

There is no when-to-use guidance, no prerequisites (e.g., needing ingredients in inventory, needing to look up recipe names via list_recipes first), and no statement of when to prefer this over machine crafting. The agent must infer the whole selection 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 full burden; it does usefully disclose that nothing is built (a non-mutating, freeze-style operation). It says nothing about validation behavior, failure modes, permissions, or whether the plan is persisted for later apply_plan.

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 lines, front-loaded with the action and immediately followed by the payload format. No filler, though the direction enum values are listed without explanation, which is terse at the cost of clarity.

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 values need no explanation. However, for a plan-construction tool with 0% schema coverage, the missing guidance on 'surface', the direction encoding, and how this plan relates to the applied/previewed plan leaves real 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 coverage is 0%, so the description must compensate, and it partially does by defining the component shape {ref, position:{x,y}, direction:0|4|8|12, label?}. The meaning of the direction codes is not explained, and the required 'surface' parameter and top-level 'label' are never described.

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 ('Freeze an ordered plan of native blueprints') and adds a scope boundary ('without building anything') that separates it from apply_plan. It does not name the plan siblings explicitly, so the differentiation is implied rather than stated.

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 'without building anything' implies this is the pre-application step, but the description never says when to use this versus preview_plan, inspect_plan, or apply_plan. The agent must infer the workflow ordering from the sibling list.

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 meaningful work: it declares 'full game scripting power', frames the tool as 'administrative', and explains the return mechanism (rcon.print with helpers.table_to_json) and how to obtain the agent character via remote.call. It stops short of stating failure behavior, timeouts, or whether code runs synchronously in the game tick.

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?

Front-loaded with the purpose, then the operational hints, then the guardrail — a sensible ordering with little waste. The bare line breaks between sentences make the technical hints read slightly disjointedly, but no sentence is filler.

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

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

For a single-parameter, high-risk escape hatch with an output schema, the description covers purpose, alternatives, return convention, and scope limits. Only the operational edges (errors, execution timing, side effects on game state) are unstated, which is a minor gap given the structured fields available.

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

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

Schema coverage is 0% and the single 'code' parameter has no description, so the description must compensate; it does, by specifying that the code is Lua, how to emit return data, and the remote.call pattern for accessing the agent. It never explicitly binds this to the parameter name or states exec/error semantics, keeping it below a 5.

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 ('Run explicit administrative Lua') plus the scope boundary ('advanced game/mod capabilities not covered above'), and explicitly contrasts with the dedicated gameplay siblings. An agent can identify the tool and its niche without opening the schema.

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

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

Gives both directions: use it for advanced capabilities not covered by the other tools, and 'use the specific tools for ordinary gameplay' otherwise. It also adds a scope guard ('respect the user's task scope'), which is the right kind of guidance for an escape-hatch tool.

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

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

With no annotations, the description carries the behavioral burden; 'export' and 'exact' suggest a non-mutating, faithful serialization, and the output format is identified. It does not explain record lookup, invalid-reference behavior, or limitations for books, although the output schema covers the return shape.

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

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

A single front-loaded sentence communicates the action, supported record types, fidelity, and output format without filler. Its brevity is appropriate, though it cannot compensate for the missing reference semantics.

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 reduces the need to document return values, and the operation itself is simple. Nevertheless, the definition omits the critical source and syntax of ref and any workflow link to blueprint_catalog or capture_blueprint, leaving a required invocation detail unresolved.

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 sole parameter, ref, has no schema description, and the description never explains its accepted format or where to obtain it. At most, an agent can infer that ref identifies a blueprint or book record, which is insufficient for confident invocation.

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

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

The description gives a specific verb, resource, and output: exporting a blueprint or book record as a standard Factorio string. It does not explicitly distinguish this operation from capture_blueprint, import_blueprint, or inspect_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?

The desired end result—a standard Factorio string—implies when the tool is useful. It provides no explicit prerequisites, when-not guidance, or direction to siblings for capturing, importing, inspecting, or locating records.

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 supplied, so the description carries the burden, and it does disclose the meaningful behavioral traits: this is a non-mutating probe that also reports version and supported operations (capability discovery). It does not state whether the call has side effects or what happens on failure, but for a zero-argument probe this is solid coverage; return details are covered by the output 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?

A single short sentence, front-loaded with the verb and the three checked items. No filler, redundancy, or trailing caveats.

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

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

Given zero parameters and an existing output schema, the description covers what the tool inspects and hints at capability discovery via 'supported operations'. The only gap is that it doesn't frame the call as a prerequisite/health check relative to the many sibling tools, which would help an agent sequence 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?

The tool takes no parameters, so there is no per-parameter semantics to explain; baseline 4 applies. The description adds no parameter information and needs none.

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') and enumerates the three things verified: connection, game version, and supported operations. This clearly identifies it as a diagnostic/handshake tool, distinguishable in character from the action-oriented siblings, though it never explicitly names itself as the connectivity probe an agent should call first.

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

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

Usage is only implied: the listed checks suggest calling it to verify a live connection or discover capabilities before invoking gameplay tools, but the description never states that condition. With zero parameters there is no risk guidance needed, so the omission is minor rather than harmful.

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

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

With no annotations, the description must carry the safety profile, and it does imply a non-mutating screen by describing it as 'terrain screening' over candidate footprints. It discloses the exclusion filters (structures, water, cliffs) but says nothing about pagination behavior despite limit/offset parameters, nor whether results are sampled on a grid.

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

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

Two short sentences, front-loaded with the core behavior, with no filler. The trailing clause 'using the user's blueprint standards' is vague and adds little, keeping it from a 5.

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

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

For an 8-parameter tool with a nested 'area' object, a sampling 'step', direction and paging parameters, plus no annotations, the description leaves the caller with almost nothing on how to construct a valid call. An output schema exists, so return values need not be explained, but the input side is seriously under-described.

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?

All 8 parameters (ref, surface, area, step, limit, offset, direction, allow_resources) have 0% schema description coverage, and the description explains none of them. The only faint link is the exclusion of water/structures, which may relate to allow_resources, but that connection is never made explicit.

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 ('Find candidate footprints') plus a concrete screening criterion ('without existing structures, water or cliffs'), which lets an agent tell it apart from blueprint/plan siblings. It is not a tautology and the scope is clear, though it never states what the returned 'footprints' actually are (tiles? regions?).

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?

'This is terrain screening' plus the instruction to plan rail approaches, grid alignment and utilities separately establishes an implicit boundary on what this tool is for. However, no sibling tool is named as the alternative for those excluded tasks, so the agent must infer the routing from the sibling list rather than from the description.

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; the verb 'read' usefully signals a non-mutating operation and the scope is bounded to current/most recent. However, it is silent on what happens when no action exists, whether the call blocks until completion, or whether an unknown action_id errors — all relevant for a status-polling 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?

One front-loaded sentence with no filler; every clause contributes scope or outcome 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?

An output schema exists, so return values need not be described, and the tool is structurally simple. Still, the missing edge-case behavior (no pending action, invalid id, blocking semantics) leaves gaps for an agent that needs to poll reliably.

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

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

Schema coverage is 0% for the single optional action_id, so the description must compensate. 'Current or most recent action' does implicitly explain the null default (omit the id to get the latest action), which is real added meaning, but it says nothing about accepted id formats or invalid-id behavior.

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

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

The description gives a specific verb ('read') and resource ('action status') and even enumerates the outcomes reported (completion, cancellation, failure). It does not differentiate itself from nearby siblings such as get_agent_status or cancel_action, so the agent cannot rule out the alternatives from the text alone.

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

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

There is no explicit statement of when to call this versus get_agent_status or cancel_action, and no guidance on when to supply action_id versus relying on the default. The phrase 'current or most recent action' hints at a polling use case, but the agent must infer 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?

No annotations are provided, so the description must carry the behavioral burden; it does imply a read-only operation and signals that the data is the character's real state rather than an inferred one. It says nothing about side effects, staleness/latency, or whether reading is free of game-state consequences, which matters for a tool with no safety 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?

One short sentence with the resource list front-loaded and no filler. Every word contributes to identifying the data returned.

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 read tool with an output schema, the description covers the essentials: what is read and whose state it is. The remaining gap is routing guidance against the many status/world-inspection siblings, which the description does not address.

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

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

The tool takes zero parameters, so the schema imposes nothing to explain and the description needn't disambiguate arguments. The description does usefully enumerate what the no-arg call returns (inventory, position, action).

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 ("Read") plus a concrete resource triple (inventory, position, action) scoped to the "independent AI character". That is clearer than a bare title, but it never names the overlapping siblings (get_action_status, observe, get_world), so an agent must infer the distinction.

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

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

It states no when-to-use condition, no prerequisites, and no alternative tool to prefer for related data. The word "actual" hints at ground-truth state versus a self-report, but this is never spelled out, and several siblings clearly read overlapping state.

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 supplied, so the description must carry the behavioral load; "List" implies a non-destructive read, which is the main signal. It says nothing about cost, latency, or whether the payload is a live snapshot versus cached state, which matters for a world-state dump that could be large.

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

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

A single front-loaded sentence with no filler; every word names content the caller gets back. It is dense but readable, though the bare comma list could be grouped more clearly.

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 that already documents the return shape, the description covers what matters: that this is a read of all world-level entities. The main gap is the absence of any routing hint versus sibling inspection tools, which is a minor omission at this complexity.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the baseline applies. The description correctly implies the call needs no arguments to scope the query.

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 ("List") and enumerates the resources returned: surfaces, sandbox surfaces, players, forces and simulation state. An agent can tell this is a whole-world snapshot read. It stops short of distinguishing itself from overlapping siblings such as `observe` or `get_agent_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?

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives like `observe` or `inspect_entity`, both of which may return overlapping state. The enumerated contents only weakly imply that this is the general-purpose overview call.

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 supplied, so the description carries the full behavioral burden for a write/mutation tool, yet it never states the required payload format, whether importing overwrites existing storage, whether the operation is reversible, or what storage scope it targets. The presence of an output schema covers return values, but the mutation semantics remain undisclosed.

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

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

A single efficient sentence with the verb and scope front-loaded and no redundant wording. It is under-specified rather than bloated, so brevity is not the problem here.

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

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

For a mutation tool with zero annotation coverage, unknown payload format, and a 0%-documented parameter, the description is far too thin. The output schema excuses it from explaining results, but the input contract and storage effects an agent needs before calling it 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 description coverage is 0% on the single required parameter 'data', and the description adds no meaning: it does not say whether 'data' is a blueprint string, a JSON document, or an entire book structure. With the whole payload undocumented in both schema and prose, this is a substantive gap for a one-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 states a specific verb+resource ('Import an exported blueprint or nested book') and names the destination ('bridge-owned storage'), which pairs it clearly with export_blueprint and separates it from capture_blueprint/inspect_blueprint. It does not explicitly name a sibling to route away from, and 'bridge-owned storage' is unexplained jargon.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of prerequisites such as having an exported blueprint first or of what to do if a blueprint with the same name already exists. The implied workflow (export_blueprint → import_blueprint) must be inferred.

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

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

No annotations exist, so the description carries the burden; 'Read' implies a non-mutating snapshot and it discloses that entities are only included when the optional flag is set, which is genuine behavioral detail. However, it says nothing about what happens when ref is unknown, whether books/multiple blueprints are handled, or the cost of include_entities on large blueprints.

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 telegraphic sentence with no wasted words, and the most important content (what is read) is front-loaded. The fragment style omits a subject and reads as a list rather than a sentence, which slightly reduces clarity but not length.

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

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

An output schema exists, so the description did not need to enumerate return fields, and doing so is partly redundant. The critical gap is that for a tool whose only required input is a reference identifier, the description never explains what a ref is or where it comes from, leaving the agent unable to call it 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%, so the description must compensate. It partially does by tying 'optional full native entities' to include_entities, but the required 'ref' parameter is given no meaning whatsoever — no indication of format (name, ID, catalog key) or how to obtain a valid value. Half the parameters remain opaque.

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?

Uses the verb 'Read' against the blueprint resource (from the name) and enumerates what is returned: footprint, quantities, stations, grid snapping, and optional native entities. This is specific enough to separate it from capture_blueprint or import_blueprint, though it never names those siblings or says 'blueprint' explicitly in the prose.

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

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

There is no when-to-use guidance at all. It does not state whether the ref must point to an existing catalog/imported blueprint, nor does it route the agent to capture_blueprint, export_blueprint, or blueprint_catalog as alternatives. The agent must infer the invocation context from the tool name alone.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose one genuinely useful trait: no reach/proximity requirement. It leaves other important behavior unstated – whether the call is strictly read-only, what happens if the entity cannot be resolved, and whether the entity must be visible or loaded on the surface.

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

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

Two short, front-loaded sentences with no filler. The detail about returned contents and the reach exemption both earn their place, and nothing is restated from the schema or title.

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 values needn't be spelled out, but for a tool with four entirely undocumented optional parameters and no annotations the description is too thin. It should clarify the lookup-key combinations and the surface/position semantics to be callable without guesswork.

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

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

Schema description coverage is 0%, so the description must compensate, and it does not. It never explains that name, position, and unit_number are alternative lookup keys, nor what surface controls (default 'nauvis'), leaving the agent to guess at mutually exclusive identification strategies from bare property titles.

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 (inspect) and resource (an entity) and adds what the inspection surfaces: inventory indices and connected rails. That is clearer than a bare 'inspect_entity', but it never distinguishes this read from siblings like observe, get_world, or configure_entity, so an agent still has to infer which read tool to pick.

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

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

There is no explicit when-to-use or when-not-to-use guidance; nothing says how this differs from observe or get_world. The phrase 'No reach required' hints that it works at a distance, implicitly contrasting with mine_entity/place_entity, but that is inference rather than stated 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 supplied, so the description carries the full burden. The word 'Read' implies a non-mutating operation and 'persistent ... application state' usefully signals that the plan survives across calls and that state reflects application progress, but permissions, side effects, and failure behavior for a bad plan_id are unaddressed.

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

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

A single front-loaded sentence with no filler, and the key noun phrase 'persistent construction plan' comes early. It is efficient but so terse that it squeezes out needed qualifiers rather than being genuinely 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?

An output schema exists, so return values need not be explained, and the tool is simple with one required parameter. Still, with no annotations and no parameter documentation, the description should say more about the plan lifecycle and how plan_id is obtained for an agent to invoke it confidently.

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

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

Schema description coverage is 0% for the single parameter, plan_id, and the description adds nothing about its format or origin (e.g., whether it comes from create_plan or a blueprint import). With the schema contributing no meaning, the description should have compensated 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?

'Read a persistent construction plan and its application state' gives a specific verb (read) and resource (construction plan) plus what is returned (application state). It is clear on its own, but it never distinguishes itself from siblings like preview_plan, apply_plan, or inspect_blueprint, so a 4 rather than 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?

There is no when-to-use guidance and no alternatives named. The description does not say whether to call this before apply_plan to check progress, after create_plan to verify, or instead of preview_plan, leaving the agent to infer the position in the plan lifecycle.

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 doesn't state that this is a read-only lookup, doesn't disclose the default limit of 100 or offset pagination, and doesn't explain what "by name" means for matching behavior (prefix, substring, case sensitivity). Only the word "list"-style framing implies safety.

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

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

A single short sentence with no filler, which is structurally clean. However, its brevity here reads as under-specification rather than economy, since the space saved is not spent on any of the missing usage or parameter context.

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

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

An output schema exists, so return values needn't be described. But for a four-parameter, enum-bearing listing tool with zero annotation coverage and zero schema descriptions, the definition leaves too much unknown: pagination semantics, what kind values select, and how query matching works.

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 all four parameters, and it largely fails. "By name" is the only hint and it ambiguously gestures at the query parameter; the enum-constrained kind parameter, limit, and offset receive no explanation whatsoever, leaving the agent to infer paging and filtering from bare titles.

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?

"Discover ... prototypes" gives a verb and resource, so the broad intent (enumerate prototype definitions) is inferable. But "installed base, expansion and mod prototypes" is domain jargon that doesn't map cleanly onto the kind enum (entity/item/recipe/technology/tile), and nothing distinguishes it from the sibling list_recipes or blueprint_catalog.

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

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

No when-to-use guidance at all: no indication of when to call this versus list_recipes or inspect_entity, no note that all parameters are optional with defaults, and no mention of how to page through results. The agent must guess its role among 29 siblings.

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

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

No annotations are supplied, so the description carries the full behavioral burden, yet it only implies read-only access via the word 'Read'. It says nothing about pagination behavior, how filtering interacts with results, what 'locked' recipes mean, or any auth/permission context. The presence of an output schema excuses explaining return values, but not the call semantics.

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

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

It is a single short sentence with no padding, but it is a noun-phrase fragment that lists output fields rather than front-loading the action ('list recipes') and scope. Brevity here reflects under-specification rather than efficiency.

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 the return shape need not be described, and zero required parameters lowers the risk of misuse. However, for a four-parameter filtered-list tool with no annotations, the description omits everything an agent needs to choose arguments 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% across four parameters (limit, query, offset, include_locked), so the description needed to compensate and does not. Only the phrase 'research availability' loosely gestures at locked/research-gated content, leaving query syntax, pagination defaults, and include_locked's effect undocumented.

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

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

The description enumerates the fields returned (ingredients, products, category, energy, research availability) and implies a read of recipe data, but never states plainly that it lists recipes or what the result set represents. It also gives no differentiation from sibling tools like list_prototypes, which plausibly overlaps.

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 call this versus list_prototypes or research, nor any mention of prerequisites or typical use cases. The agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the full burden, and it does disclose two real traits: mining consumes genuine in-game time (implying a long-running, possibly blocking call) and is bounded by interaction reach (proximity requirement). However, it never states whether the entity is destroyed, what happens on timeout, whether the action is cancellable, or how results are returned.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though the phrasing "real mining time and interaction reach" is somewhat cryptic and could be stated more plainly.

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 six-parameter, zero-coverage, unannotated mutation tool, the definition is far too thin. The output schema covers return values, but nothing explains entity targeting, multi-count behavior, timeout semantics, or interruption, leaving major call-correctness gaps.

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

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

Schema description coverage is 0% across six parameters, so the description must compensate and largely does not. It never explains name, count, surface, unit_number, or position, and only loosely gestures at timeout via "real mining time"; an agent must guess which entity selector to use and what count=1 does.

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+resource pair ("Mine resources or recover structures") that clearly identifies a harvesting operation distinct from placement or inspection siblings. It stops short of explicitly differentiating itself from siblings like inspect_entity or cancel_action, which an agent might reasonably confuse with an in-progress mining 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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternatives among the many siblings. The phrase "interaction reach" only implicitly hints that the player must be near the target, and nothing says when to prefer this over cancel_action or move_to.

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

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

With no annotations, the description carries the full burden, and it does disclose two meaningful traits: movement is pathfound (not instantaneous/teleport) and the call is asynchronous, returning an action ID. It says nothing about failure modes, what happens if the target is unreachable, whether the action is cancellable, or how the timeout interacts with the walk. That is useful but thin for an unannotated 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?

Two short sentences, front-loaded with the core mechanism and then the key constraint. Nothing is padded, though the extreme terseness leaves obvious gaps that a clause or two could have closed without bloat.

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 values need not be explained, but the description still leaves the agent unequipped: five parameters at 0% coverage, no annotations, and no statement of prerequisites or post-call workflow. For a multi-parameter asynchronous movement action, this is substantially 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?

Schema description coverage is 0% across five parameters (x, y, within, surface, timeout), and the description explains none of them. Units (tiles?), what "within" tolerance means, what "surface" selects, and what "timeout" bounds are all left undocumented. The description adds zero meaning beyond the bare 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?

"Walk with the engine pathfinder" conveys that the agent moves under engine pathfinding rather than teleporting, which is a real verb+mechanism. But it never states that the tool moves the agent to a target coordinate, so the resource/destination is only implied by the parameter names. It also does not differentiate itself from siblings like create_plan/apply_plan that could also cause movement.

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

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

There is no explicit when-to-use guidance and no alternatives named; the only usable cue is "Returns an action ID," which hints the call is asynchronous. An agent must infer on its own that it should follow up with get_action_status or cancel_action. No exclusions or preconditions (e.g., reachability) are given.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose two real traits: pagination behaviour is independent of entity type, and `detailed` enriches results with fluid/inventory/recipe/power/rail-connection data where supported. However it does not state the read-only/no-side-effect profile explicitly, does not explain how limit/offset interplay, and does not say what happens when area, radius and position are combined.

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, front-loaded with the core action, with no filler. The inline `area` shape note is placed usefully, though the block formatting makes it read slightly like an afterthought rather than an integrated parameter note.

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-value explanation is rightly omitted, and the tool's core read semantics are conveyed. But for a 9-parameter tool with zero schema descriptions and no annotations, coverage of only 2 parameters leaves the agent guessing on most of the surface area, particularly the spatial-filtering parameters.

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% across 9 parameters, so the description must compensate and largely fails to. It documents only the shape of `area` ({left_top, right_bottom}) and the effect of `detailed`; limit, offset, radius, surface, names, types and position are left entirely undefined, including the important question of precedence between `area`, `radius` and `position`.

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?

"Read any entity prototypes in an area" names a specific verb and resource, and the following sentences make clear it returns world entities with their state data. It is distinguishable from a single-entity read, but the description never names inspect_entity or find_sites, so the boundary with siblings is left to the agent. The word "prototypes" is also slightly off-terminology for what is effectively an area scan of live entities.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative is named despite inspect_entity (single entity) and find_sites (search) being obvious near-neighbours. The agent must infer from "in an area" that this is the bulk/area read. That is implied usage only, with no exclusions.

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

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

With no annotations, the description carries the full behavioral burden. It discloses meaningful traits: no entity whitelist, engine-side collision and placement-rule checks, inventory requirement, and normal-reach constraint. However, it does not explain failure behavior, whether items are consumed, or mutation side effects, leaving gaps for a placement/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?

Four short sentences, front-loaded with the action and immediately followed by key constraints and the blueprint alternative. No filler, though the term 'item.place_result prototype' could be simplified for readability.

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 purpose, high-level placement behavior, and the main alternative. An output schema exists, so return values need not be described. But for a tool with five parameters, a nested position object, and an enum, leaving all parameter semantics undocumented is a clear completeness gap.

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

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

Schema description coverage is 0% across five parameters, including a nested position object and an underground_type enum. The description only implicitly hints that the item must be a placeable prototype from inventory; position, direction, quality, and underground_type are not explained at all, so it largely fails to compensate for the schema gap.

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

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

States a specific verb (build/place) and resource (any item.place_result prototype), and distinguishes the tool from blueprint plans for complete layouts. The Factorio-specific phrasing 'item.place_result prototype' is slightly jargon-heavy but still clear enough for an agent in this domain.

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

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

Names an explicit alternative and when to use it: 'For complete layouts, tiles, wires and settings, use native blueprint plans.' Also states the reach constraint and that there is no entity whitelist. It does not explain when to prefer this over configure_entity, but the key exclusion is present.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the important traits: overlays are temporary, and nothing persistent is created (no ghosts, no robot construction). It does not say whether the overlay blocks other calls, whether it requires an active session/client connection, or what happens if seconds is large, so the disclosure is partial.

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

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

Two short sentences with the action front-loaded and the key exclusion second. Nothing is padded, though the terse phrasing leaves the sentences doing less work than they could.

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 values need not be described, but the definition still leaves gaps for a two-parameter tool: the meaning and bounds of seconds, and where plan_id comes from. Adequate as a minimum, 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 description coverage is 0% and neither parameter is explained. The description adds no meaning for plan_id (presumably the plan from create_plan) or for seconds, whose role as overlay duration has to be guessed from the name and default of 60.

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

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

The description gives a concrete verb and resource ('Draw temporary footprint overlays') and implicitly separates the tool from apply_plan by stating it does not create ghosts or start robot construction. It never explicitly ties the action to a plan created by create_plan, but an agent can still tell what the call 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?

Usage is only implied: the 'does not create ghosts or start robot construction' clause signals this is a dry-run/visual check, which suggests calling it before apply_plan. There is no explicit when-to-use, no exclusion of inspect_plan, and no stated prerequisite that a plan must already exist.

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 supplied, so the description carries the full burden. It hints at a mutation ("queue a technology") without saying what is queued, whether the queue is additive or replacing, what force is affected, or what permissions/side effects apply. The dual read/write nature is the most important thing to disclose and it is left ambiguous.

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

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

It is a single compact sentence with no padding, but the brevity comes at the cost of ambiguity rather than being achieved through precision. The read portion is front-loaded, which is the right structure.

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 values need not be described. However, for a tool with two distinct modes and two undocumented parameters, the description omits the one thing an agent needs: how to invoke the optional queue behavior. It is adequate only for the read path.

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 neither parameter is named in the description. "force" (default "player") and "start" (nullable string) are completely unexplained, and the description's mention of queueing does not map onto either name, so the agent must guess which field selects a technology.

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?

"Read research and available technologies" gives a verb and resource, but the second clause "optionally queue a technology normally" is opaque — "normally" is undefined and no parameter named technology exists in the schema. An agent cannot tell precisely what state is read or how a queue action is triggered.

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

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

No guidance on when to call this versus siblings such as list_prototypes, list_recipes, or get_world, which all surface game data. The read-vs-queue choice is presented as an option with no condition that selects 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 full burden and does disclose meaningful traits: execution is tick-by-tick by the mod, firing is time-bounded, and it consumes real weapons/ammo. It omits failure modes, range/line-of-sight constraints, whether the agent must be equipped, and what happens when ammo runs out mid-duration.

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

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

Two short sentences, front-loaded with the action and duration, followed by a caveat that genuinely earns its place. The 'Aim/shoot' slash phrasing is slightly informal but costs nothing.

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 values need not be explained, and the core mechanics (tick execution, ammo use, duration) are covered. Still, for a combat primitive with zero annotation coverage and an undocumented nested position parameter, the description should say more about requirements and failure conditions.

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% with two parameters, one of which is a nested position object with unconstrained numeric properties (no x/y keys documented). The description only loosely gestures at 'bounded duration' for seconds and 'aim at' for position; it does not clarify the coordinate shape or what the seconds default of 2 means in practice.

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

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

States a specific verb pair (aim/shoot), the resource consumed (real weapons/ammo), and the temporal scope (bounded duration, executed per tick). It is clearly distinguishable from movement/mining/crafting siblings, though it does not explicitly name what it is not.

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

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

Usage is implied by 'aim/shoot' at a position, and the second sentence sets a negative expectation by warning this is not reliable autonomous combat. However, it gives no positive when-to-use conditions, no prerequisites (weapon equipped, ammo available, line of sight), and no mention of cancel_action for stopping.

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 usefully discloses the precondition that writes must target exactly one explicit train_id and that the schedule field follows Factorio's TrainSchedule structure, plus the boundary that groups/interrupts are out of scope. It omits what a call with all-null arguments returns, whether a schedule replacement is destructive, and how the five optional fields interact when combined.

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 dense sentences with the primary read/write purpose front-loaded and the caveat about advanced scheduling after it. No filler, though the semicolon-joined second sentence reads as a stack of caveats rather than a clearly ordered structure.

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 values need not be described. But for a five-parameter, unannotated tool that both reads and mutates train state, the description leaves too much open: parameter meanings, the all-null default behavior, and the effect of mutations are all absent.

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% across five parameters, so the description must compensate and largely does not. It explains only 'schedule' (TrainSchedule structure) and the intent of 'train_id'; 'surface', 'manual_mode', and especially 'go_to_station' (typed as an integer, which is non-obvious for a station target) are left entirely undefined.

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 first clause names a concrete verb+resource pair ('Inspect trains, schedules and carriages') and the second states the write path ('modify one explicit train ID'). The read/write duality is stated plainly, though the combined scope makes it slightly harder to tell which mode a bare call triggers. It does gesture at a sibling ('get_schedule() in the advanced Lua tool'), which helps separate it from execute_lua.

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?

'modify one explicit train ID when requested' implies a prerequisite (train_id must be supplied for any mutation), and the note about groups/interrupts routes advanced scheduling work to execute_lua. However, no guidance is given for the other likely alternatives in the sibling list (inspect_entity, configure_entity, move_to), and nothing says when to call this with no arguments versus a populated one.

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

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

With no annotations, the description carries the full burden. It does disclose useful behavior beyond the schema: 'nearby' establishes a proximity requirement, 'real items' signals actual game-state mutation, and 'No per-entity role whitelist' describes the targeting permission model. It omits what happens on partial transfers, full inventories, or out-of-range entities, which matters for a 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?

Three short sentences, front-loaded with the core action, then the inventory discovery hint and the permission note. No filler, though the 'No per-entity role whitelist' sentence is terse to the point of being cryptic for an unfamiliar agent.

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 values need not be explained, but the tool is a 9-parameter mutation with zero annotation coverage and zero schema descriptions. The description leaves the majority of parameters (quality, count semantics, position/surface, unit_number) and failure behavior undocumented, which is not enough 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 0% across 9 parameters, so the description must compensate. It explains only 'inventory' (numeric index or defines.inventory name); item, count, quality, name, surface, position, and unit_number get no explanation at all, leaving most of the argument surface opaque.

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

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

The description gives a specific verb and resource ('Transfer real items to/from a nearby entity') and the directionality is clear. It does not explicitly contrast itself with siblings like place_entity or craft, but the resource being moved 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?

It implies a workflow ('Discover inventory indices with inspect_entity') and a permissive condition ('No per-entity role whitelist'), which helps an agent know it can target arbitrary entities. However, it never states when to choose transfer_items over alternatives such as place_entity or craft, so usage is only implied.

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