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

With no annotations, the description carries the full behavioral burden, but it does not disclose whether the copy overwrites existing blocks, what happens at boundaries, or whether source and destination can overlap. It does mention the source default and lowest-corner alignment, which is useful but insufficient 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?

The description is a single front-loaded sentence with no wasted wording. It is concise, though its brevity contributes to the broader completeness gaps.

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 11-parameter mutation tool with no annotations and 0% schema description coverage, the description is far too sparse. An output schema exists, so return values need not be explained, but coordinate semantics, overwrite behavior, and the name parameter remain unclear.

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 explain the 11 parameters. It only clarifies source (optional, defaults to the same structure) and the destination corner concept, leaving the coordinate pairs and name parameter largely 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 description states a specific verb and resource: copy a box/region from a source to a destination. It is more informative than the name alone and conveys the alignment rule, though it does not explicitly distinguish itself from siblings such as fill or replace_blocks.

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

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

It gives no explicit guidance on when to use this tool versus alternatives like fill, replace_blocks, or set_blocks. The source/default behavior is mentioned, but exclusions and selection criteria are absent.

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 load. It does disclose important behavior: the mutation semantics of each mode and that state 'void' clears positions (a destructive effect). It omits which structure is targeted (the 'name' parameter is unexplained), whether this requires an opened structure, and whether the change is undoable despite an 'undo' sibling existing.

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 core action, then a compact mode table in one sentence, then the void-clearing note. Dense and waste-free; slightly terse given how much parameter surface is undocumented.

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 covers return values, so no credit is needed there. But for a 9-parameter mutating tool with 0% schema coverage, missing target-structure semantics and coordinate/name documentation leave real gaps before an agent can call 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%, so the description must compensate, and it does document all five mode enum values plus the 'void' clearing behavior for state, which is genuinely beyond the schema. But it says nothing about the 'name' parameter, the x1/y1/z1 vs x2/y2/z2 pairing, or coordinate conventions, leaving the majority of 9 parameters undocumented anywhere.

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

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

States a concrete verb and resource ('Fill a box') with a scope qualifier ('inclusive corners'), which tells an agent exactly what the operation affects. It does not distinguish itself from siblings like set_blocks or replace_blocks, which also write blocks, so the agent must infer the boundary.

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 mode enumeration gives implicit guidance: an agent can pick 'replace' vs 'hollow' vs 'walls' from the described semantics. However, there is no statement of when to prefer fill over set_blocks/replace_blocks/copy_region, no mention that a structure must already be open, and no exclusions or prerequisites.

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 load, and it does disclose two real traits: the output is a legible character map with a legend, and it is cheap and exact (cost/precision tradeoff vs rendering). It leaves open prerequisites such as whether the structure must be opened first and what happens for an out-of-range y.

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

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

Two sentences, no filler; the return format is front-loaded and the routing advice follows immediately. Every clause earns its place.

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

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

An output schema exists, so return values needn't be explained, and the description covers format and cost well. However, with two fully undocumented parameters and no annotations, the definition leaves the meaning of 'name' and the structure state requirements unaddressed.

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 never mentions either required parameter. The axis convention implies y selects the layer, but 'name' (presumably the structure identifier) is entirely undocumented, so the description does not compensate for the coverage 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 the specific resource and its exact form: one horizontal layer returned as a character map with row/column axes defined (rows = z, columns = x) plus a legend. It also differentiates itself from render/render_layer, so an agent can pick it without opening any 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?

Explicitly splits the decision: use this to check positions, use render/render_layer to see appearance. That names both the condition and the alternative, leaving nothing for the agent to infer.

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

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

No annotations are provided, so the description carries the disclosure burden. It usefully states that results include both session-open structures and workspace .nbt files, but it does not explicitly say the operation is read-only or side-effect-free, which would be helpful for an unannotated list tool.

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

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

The description is extremely short and front-loads the scope, but it is written as a fragment rather than a complete sentence. It avoids waste but is borderline under-specified for an unannotated tool.

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

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

Given that the tool has zero parameters, a simple listing purpose, and an output schema that documents return values, the description is largely complete. It only lacks a brief read-only affirmation, which is minor for a list operation.

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

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

The tool takes zero parameters, so there is no parameter semantics for the description to add. The baseline for a parameterless tool is 4, and the schema is fully covered.

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

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

The description identifies exactly what the tool lists: structures open in the current session plus .nbt files in the workspace. It is clear enough to distinguish this from siblings like structure_info or open_structure, though it omits an explicit verb and only implies the listing action via the tool name.

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

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

There is no explicit guidance on when to use this tool versus siblings such as structure_info or open_structure. The narrow scope implies it is for discovering available structures, but no alternatives or exclusion conditions are stated.

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

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

With no annotations, the description carries the full burden. It usefully discloses the initial void state and the DataVersion upgrade semantics, but says nothing about whether creating clobbers an existing structure of the same name, whether it needs an explicit save, or what happens on invalid sizes.

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

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

Two tight sentences with the core action front-loaded and no filler; the parenthetical and version note both carry real 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 no explanation, but for a mutating create tool with 4 undocumented required parameters and no annotations, the description leaves key gaps: overwrite behavior, persistence/save lifecycle, and size validation.

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% across 5 parameters. The description meaningfully explains only minecraft_version (defaulting semantics and upgrade behavior); name, size_x, size_y and size_z are undocumented in both schema and description, including units or valid ranges for the dimensions.

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

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

The description opens with a specific verb+resource ('Create an empty structure') and clarifies the initial state (structure void until blocks are placed), which separates it from open_structure and save_structure. It does not explicitly name those siblings, so it stops short of a 5.

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

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

There is no explicit when-to-use vs. alternatives guidance, e.g. no mention that you later call save_structure or that open_structure handles existing files. The minecraft_version advice ('use the OLDEST version you target') is genuine usage guidance but applies to one parameter, not the tool choice.

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

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

No annotations are provided, so the description carries full behavioral burden. It does add one useful rule - relative paths resolve inside the workspace - but says nothing about what happens on a missing/invalid file, whether the current structure is replaced, or whether unsaved edits are affected, which matters for a state-loading operation.

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

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

A single front-loaded sentence with the path-resolution caveat attached inline - nothing wasted. There is spare room that could have been used on the name parameter or file-missing behavior.

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

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

An output schema exists, so return values need not be explained, and the safety profile is simple. However, for a tool that loads state into a workspace, the missing notes on 'name', on failure modes, and on replacing an already-open structure leave it only minimally adequate.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify 'path' by stating relative paths resolve to the workspace, but the optional 'name' parameter is never mentioned, leaving half the parameters undocumented in both schema and description.

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

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

Names a specific verb ('Open') and resource (a structure .nbt file), so the operation is unmistakable and clearly distinct from siblings like new_structure, save_structure and list_structures. It stops short of explicitly contrasting itself with new_structure, but the action is unambiguous.

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

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

The description gives no guidance on when to choose this over new_structure or list_structures, and no prerequisites such as the file existing or replacing any currently open structure. Usage is only inferable from the verb 'Open'.

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: output is persisted to <workspace>/renders/ and cut_y removes geometry above a height to expose interiors. It omits return behavior (inline image vs. path), persistence/overwrite semantics, and any size or performance limits, which matter for a render operation.

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

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

Three short clauses, front-loaded with what the tool produces, then the two non-obvious parameters. Dense and free of filler; only the trailing side-effect note is slightly detached from the parameter explanations.

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

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

No output schema and no annotations means the description is the only source of truth, yet it says nothing about what the agent receives back, whether an open structure is required, or what scale/max_size control. For a 5-parameter render tool this leaves significant 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% across 5 parameters, so the description must compensate. It explains view and cut_y reasonably well, but leaves the required 'name' parameter, 'scale' and 'max_size' completely undefined, so more than half the inputs 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?

States a specific action and output: an isometric render using the game's textures. That is clearly distinct from the layer-oriented sibling render_layer, though the description never names render_layer explicitly to sharpen the contrast.

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

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

No guidance on when to use this versus render_layer, nor any prerequisites such as whether the structure must be opened first or what 'name' refers to. The only contextual clue is an incidental note that output is saved under <workspace>/renders/.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the output's appearance — top-down view, floor below faded, grid and coordinate overlay — which is real behavioral value, but it says nothing about side effects (does it write a file? is it read-only?), permissions, or whether the structure must already be loaded.

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

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

A single well-formed sentence with the core purpose front-loaded and no filler; the parenthetical for the faded floor is efficient. It is arguably over-terse given the parameter ambiguity, but nothing in it is wasted.

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

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

With no annotations, no output schema, and 0% parameter coverage, an agent must still guess what 'name', 'cell', and 'max_size' expect and whether the call has any side effects. The output-appearance detail is welcome but does not compensate for these 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 4 parameters, and the description explains none of them. 'One layer' faintly hints that 'y' is the layer index, but 'name', 'cell' (default 20), and 'max_size' (default 900) are entirely opaque — 'cell' and 'max_size' in particular have no evident meaning without description text.

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

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

States a specific verb+resource ('top-down plan of one layer') and, by scoping to 'one layer', implicitly distinguishes itself from the sibling 'render' which presumably covers the whole structure. That differentiation is inferable rather than stated outright, which keeps it from a 5.

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

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

The phrase 'one layer' implies when this tool is appropriate versus the full 'render' sibling, but there is no explicit when-to-use/when-not guidance, no named alternative, and no prerequisites (e.g., must a structure already be open?).

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 disclosure burden. It does add genuinely non-obvious behavior — that a bare name like 'stone_bricks' matches every state of that block — which an agent could not infer from the schema. However, it says nothing about persistence of the mutation, whether the change is undoable, or whether a structure must be open first, all of which matter for a write operation.

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

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

Two short sentences, zero filler, and the core operation is front-loaded ahead of the matching-rule clarification. Every sentence carries 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. But for a 9-parameter mutation tool with no annotations, the description leaves out coordinate semantics and preconditions (open structure, undo), so it is only marginally 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% across 9 parameters, so the description must compensate and it only partly does. It gives real meaning to 'old' and 'new' (block name vs. full state, with bare-name wildcard semantics) that the schema lacks, but the six x1/y1/z1/x2/y2/z2 box parameters are only obliquely referenced as 'a box' with no indication of which parameter is which corner or whether partial bounds are allowed.

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 ('Replace one block ... with another') plus a scope ('whole structure or a box'), so the operation is unambiguous. It does not name or differentiate itself from closely related siblings like set_blocks or fill, which do similar block-writing work.

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?

'in the whole structure or a box' implies two modes of use and implies that omitting coordinates targets the entire structure, but this is never stated explicitly. There is no guidance on when to pick replace_blocks over set_blocks or fill.

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 disclosure burden, and it does surface the most important trait: shrinking discards blocks outside the new bounds, which makes the tool destructive. However, it says nothing about permissions, whether the operation is undoable, whether growing pads with air, or what happens on invalid sizes.

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

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

A single front-loaded sentence with the destructive caveat efficiently parenthesized; nothing is wasted. It is arguably too terse for a four-parameter mutation tool, but there is no filler.

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

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

An output schema covers the return value, but for a destructive, four-parameter mutation with zero schema documentation and no annotations, the description leaves out parameter meanings, preconditions, and error behavior. An agent could call it, but not 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 coverage is 0%, so the description must compensate. It conveys that size_x/size_y/size_z define the new bounding box, but it never explains the 'name' parameter or the unit/constraint semantics of the dimensions, leaving half the intent to inference from parameter names.

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

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

States a specific verb and resource (change the size of a structure) and adds the key side effect that blocks outside the new size are dropped. It does not differentiate itself from siblings like new_structure or copy_region, but the operation itself is unambiguous.

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

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

There is no guidance on when to resize versus recreating a structure with new_structure or how resizing interacts with other edits. The only implied usage cue is the truncation warning, which tells the agent to be careful but not when to pick this tool.

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

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

With no annotations, the description carries the full disclosure burden. It does reveal the serialization format (gzipped .nbt) and default destination, but says nothing about overwrite behavior, whether it requires an already-open structure, error conditions, or permissions — critical for a write/serialize 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?

A single front-loaded sentence with no waste. It is efficient, though arguably under-specified rather than concise — the parenthetical default is the only supporting detail.

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

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

An output schema exists, so return values need not be explained. However, for a save operation with zero annotations and no parameter descriptions, the definition omits overwrite/error behavior, leaving the agent with gaps about side effects.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that name feeds the default path pattern (<workspace>/<name>.nbt) and implies path overrides it, which adds real meaning, but does not clarify path semantics such as absolute vs relative or whether directories are created.

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 ('Save ... structure') plus the output artifact format (.nbt, gzipped), which clearly distinguishes it from siblings like open_structure, new_structure, or list_structures. It stops short of explicitly naming those alternatives, but the action is unambiguous.

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

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

No guidance on when to use this versus open_structure or new_structure, no prerequisites, and no mention of what happens if the target already exists. The agent must infer the workflow 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?

No annotations are provided, so the description carries the full burden. It does not say whether existing NBT is overwritten or merged, whether the operation fails on non-block-entity blocks, whether a world must be loaded, or whether the change is undoable (a sibling undo exists). Only the SNBT format hint is disclosed.

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

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

Two short lines with no padding and the example is front-loaded, which is good. However the brevity comes at the cost of under-specification rather than efficiency, and the embedded NBT snippet is cryptic without stating what it is an example of besides 'chest contents'.

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. For a five-parameter mutation tool with zero annotation and zero schema-description coverage, the description is thin: it omits prerequisites, overwrite semantics, and coordinate/name meaning that an agent needs to call it correctly.

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

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

Schema coverage is 0% with five required parameters named only by bare titles. The description usefully illustrates the snbt format with a concrete SNBT example, but leaves x/y/z/name unexplained and never states that name is the block id or that the coordinates identify the target block entity.

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

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

The description names a specific action (attach NBT to a block entity) but never says it operates on the block at the given x/y/z coordinates, nor how it differs from siblings like set_blocks or fill. An agent can infer the general intent, but not the scope or the target of the operation.

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

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

There is no guidance on when to use this instead of set_blocks, fill, or replace_blocks, and no prerequisites (e.g. the block must already exist and be a block-entity type such as a chest). The one example given is about data format, not usage selection.

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

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

With no annotations, the description carries the full burden. It does usefully disclose the special "void" semantics (removes the position, left untouched when the structure is placed) versus "air" (places air) — a genuinely non-obvious behavioral distinction. However it omits permission requirements, whether prior blocks are overwritten, and undo availability for what is clearly 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 with the core action and example front-loaded, then the edge-case state values. Dense but every sentence carries information; minor cost is that the example arrives before the reader knows what name refers to.

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. For a two-parameter mutation tool with zero schema coverage and no annotations, the description still leaves gaps: the name parameter and the structural prerequisites for placing blocks are unaddressed.

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

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

Schema description coverage is 0% for both parameters. The description compensates for the blocks parameter by giving an explicit object example with x/y/z/state keys and explaining the state field's special values. The required name parameter is never mentioned, leaving its meaning and relationship to the siblings' structure names 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?

States a specific verb and resource: "Place many blocks at once" with an inline example payload, which is unambiguous about what the tool does. It does not distinguish itself from the sibling tools replace_blocks, fill, or set_block_nbt, so an agent must infer which bulk-write tool applies.

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 statement of when to prefer this over fill, replace_blocks, or set_block_nbt, and no prerequisites such as whether a structure must be open or named first. The only usage hint is the embedded example, which shows syntax rather than selection criteria.

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

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

With no annotations, the description carries the full behavioral burden and does little. It implies a read-only inspection of a structure but never says so, nor does it mention permissions, whether the tool mutates state, or how the `name` is resolved.

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 fragment is terse to the point of under-specification rather than efficient. It is short but not structured: no verb, no subject, no routing information.

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

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

The presence of an output schema means return shape needn't be described, but for a two-parameter tool with a required `name` and an ambiguous `top`, the description leaves key calling details unanswered (what name means, what top limits, prerequisites).

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 explain the parameters, and it does not. `name` is completely unexplained, and `top` (default 25) is only obliquely hinted at by 'most used block states' with no stated link between the parameter and the limit.

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 fragment 'Size, block count and the most used block states' conveys what data comes back from a structure, but there is no verb and no resource statement beyond the name 'structure_info'. It also fails to distinguish itself from siblings like list_structures or render, which an agent could plausibly confuse it with.

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_structures, open_structure, or render. Nothing states prerequisites, such as whether the named structure must already be open or loaded.

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 one meaningful behavioral trait: history is bounded to 30 steps. It omits whether undo is itself undoable, whether the history persists across sessions, and whether it is scoped to a document or global. Adequate but incomplete 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?

One short sentence, front-loaded with the action and followed by the bound. Efficient, though the terseness contributes to the ambiguity around the parameter.

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

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

An output schema exists so return values need not be explained, but the unexplained required parameter and the absence of any note on irreversibility, scoping, or history exhaustion leave real gaps for a mutation tool with no annotations.

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

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

The single required parameter 'name' has 0% schema description coverage and the description says nothing about it. Whether 'name' identifies the structure/document being undone or something else is left entirely ambiguous, so the description fails to compensate for the schema gap.

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

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

States a specific verb and action ('Undo the last edit') with a concrete bound ('up to 30 steps'), which is enough to distinguish it from the construction/rendering siblings. It does not explicitly say what is being undone (structure edits vs. block edits), but the intent is clear.

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 undo versus correcting via replace_blocks/set_blocks, no mention of a redo counterpart, and no statement about what happens once the 30-step history is exhausted. Usage must be inferred entirely.

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