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 explain hollow shell, open walls, and edge frame geometry, but it does not disclose whether existing blocks are overwritten, permissions needed, or other mutation side effects.

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

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

The description is a single front-loaded sentence with no wasted words. It packs the core operation and all mode definitions efficiently.

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

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

The tool has nine parameters, eight required, no annotations, and 0% schema description coverage. Although an output schema exists and return values need not be explained, the description omits critical input semantics and mutation behavior, so it is not complete enough for confident 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 nine parameters exist, yet the description only explains the optional mode values. The required coordinates, block material, and target design are left undocumented, so it does not compensate for the schema gap.

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

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

The description uses a specific verb and resource: 'Fills a box between two corners,' and it clarifies the result via four fill modes. It does not explicitly distinguish this tool from siblings like cylinder, sphere, or line, but the operation is still clear from the name and text.

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

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

The description explains the available modes but does not say when to use this tool rather than alternatives such as line, cylinder, sphere, replace, or copy. There is no guidance on exclusions or prerequisites, leaving tool selection to inference 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 at all, the description carries the full burden; it does signal that this is a destructive bulk-removal ('Removes every block') rather than a fill, which is the most important trait. However, it says nothing about reversibility/undo, whether the region is inclusive of boundary coordinates, whether it requires the design to be open, or what happens to blocks outside the box.

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

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

A single sentence with the destructive action front-loaded and the clarifying examples carried in a short parenthetical. No filler and nothing is buried.

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

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

An output schema exists, so return values need not be explained, but for a 7-required-parameter destructive mutation with no annotations and no per-parameter schema descriptions, the description is thinner than ideal. It conveys intent and the rough meaning of the coordinate set, but leaves region semantics and safety context to inference.

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

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

Schema coverage is 0% and parameters are named only X1/Y1/Z1/X2/Y2/Z2 with no titles beyond those names, so the description is doing real work by indicating that the six integers define a three-dimensional box region and that 'design' selects the target. It still does not clarify inclusivity of the corners, coordinate units, or the expected format of the 'design' identifier.

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: 'Removes every block in a box', with a parenthetical that clarifies the operation (doors, windows, hollowing out). An agent can distinguish this from siblings like set_block, replace, or box, though the description never names those alternatives 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?

The parenthetical examples (doors, windows, hollowing out) imply when to reach for this tool, but there is no explicit when-to-use/when-not guidance and no sibling is named as an alternative. Usage has to be inferred from the examples rather than stated.

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

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

No annotations exist, so the description carries the full burden. It does disclose a genuinely useful behavioral detail — that facing and axis block states are rotated along with the blocks — but it never says whether the source region is preserved, what happens to blocks already occupying the destination, or what the operation overwrites.

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

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

Two sentences with no filler, but the first is a dense run-on whose clause order ("a box dx, dy, dz on") obscures the offset/region relationship instead of front-loading it. Compact, yet the awkward phrasing costs comprehension.

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

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

For a 12-parameter geometry mutation with zero annotation coverage and no schema descriptions, the description is too thin: the coordinate extent parameters are undefined and the phrase "within the box" leaves the target region ambiguous. An output schema exists, so return values need not be described, but the input semantics are 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 12 parameters, so the description must compensate and it covers only dx/dy/dz, mirror, and turns. It usefully reveals that mirror accepts "x" or "z" (the schema has no enum), but design, x1/y1/z1/x2/y2/z2 are never defined, leaving the agent to guess that they are the source box corners.

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: copies the blocks of a box region with an offset (dx, dy, dz), optionally mirrored or rotated. Parenthetical examples ("repeat a window, a pillar, a wing") and the mirror/turn modifiers make the intent distinguishable from siblings like box or symmetrize, though the first sentence is grammatically tangled and takes effort to parse.

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 through the examples of what copying is for (windows, pillars, wings). There is no explicit guidance on when to use this versus box (creates fresh geometry) or symmetrize (mirrors a whole design), and no stated 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 at all, the description carries the full burden and does add meaningful behavioral detail: the +axis direction convention, first-end centering, and what hollow does. However, it never says this mutates the current design, whether it overwrites existing blocks, or what happens at the far end. Substantial but incomplete disclosure 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 dense sentences with the anchoring and orientation semantics front-loaded and no wasted words. Slight awkwardness in 'running length blocks along +axis', but the structure is efficient.

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

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

An output schema exists so return values needn't be explained, but with 9 params, 7 required, 0% schema coverage, and zero annotations, the description leaves radius, block, and design unexplained and never states that this writes into the active design. Too many gaps for a geometry mutation tool with no structured support.

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 all 9 params, yet it covers only x/y/z anchoring, length, axis direction, and hollow. Radius — a core, required cylinder parameter — is never mentioned, nor are block or design, leaving a critical gap on how the cylinder's width is determined (and how radius interacts with hollow).

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 makes it clear this draws a cylinder vs the sibling primitives (box, sphere, pyramid, line), stating the anchoring point (first end at x,y,z) and that it runs length blocks along +axis. The parenthetical 'y: a tower, x or z: a tunnel or arch' makes the shape's effect concrete. It lacks an explicit verb (create/draw) but the resource and behavior are unmistakable.

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 axis examples ('tower' vs 'tunnel/arch') hint at when each orientation fits, and 'hollow leaves a tube' hints at the tube use case. There is no explicit when-to-use-this-vs-box/sphere guidance and no stated prerequisites such as an active design.

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 important side effects: it writes a file into a data pack and creates `pack.mcmeta` if none exists. However, it does not state overwrite behavior, required permissions, or error conditions 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 target path is front-loaded in the first sentence, and the remaining sentences add relevant file-creation and in-game-use details. It is somewhat long, but each clause contributes useful operational 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?

The output schema means return values need not be described, and the core export destination and pack behavior are covered. Still, for a mutation tool with no annotations and 0% parameter descriptions, the missing explanation of the `description` parameter and overwrite semantics leaves meaningful gaps.

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

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

Although schema description coverage is 0%, the description ties `namespace`, `design`, and `datapack` together through the path template and explains the special `.litematic` path case. It leaves the `description` parameter entirely unexplained, so it only partially compensates for the schema gap.

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

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

The description clearly states the specific verb and resource: it writes the design as a `.litematic` file at a concrete path template. It is easy to distinguish from construction siblings like `box` or `set_block`, though it does not explicitly name alternatives.

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 useful post-export context — after `/reload` the blueprint is available via the Blueprint item and bots can build it — but it does not explicitly say when to choose `export` over adjacent tools such as `preview` or `open_schematic`. Usage is strongly implied rather than stated with 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 behavioral burden and does disclose the important conventions: north is up, x runs right, y counts from the bottom, letters are blocks and '.' is air. That is meaningful context an agent cannot get from the bare schema. It does not state whether the operation is read-only, though "checking" implies it, and the output form is partly 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 dense sentence with the orientation convention front-loaded and no filler. The grammar is slightly compressed ("a letter a block"), but every clause 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?

For a two-parameter read tool with no annotations and an output schema, the description covers the output semantics well but leaves the 'design' input unexplained and never explicitly confirms the operation is side-effect free. Adequate, with a clear remaining 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%, so the description must compensate for both parameters. It clarifies the 'y' parameter's origin ("y counted from the bottom"), which is genuinely useful, but says nothing about 'design' — whether it is a name, id, or handle, or how to obtain one. 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?

The description states concretely what is produced: one horizontal slice of the design rendered as text, with orientation and glyph legend. It implicitly distinguishes from the whole-view 'preview' sibling, though it never names it. The phrasing is cryptic but the resource and output form are unmistakable.

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?

"For checking exact positions" gives an intended use case, which is real guidance. However it names no alternative (e.g. preview for a full view, box/line for bulk edits) and states no when-not conditions, so the agent must infer when a single-layer dump beats other inspection 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 full behavioral burden for a mutating build tool. It discloses that the line is one block thick and supports diagonals, but says nothing about writing into the design, overwriting existing blocks, material consumption, or failure cases.

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 only one short sentence with no padding, but for an eight-parameter mutation tool this is under-specification rather than conciseness. The one sentence that exists is front-loaded but does not earn its place as a complete definition.

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 still has 8 required params, 0% schema coverage, and no annotations. The description leaves out coordinate meaning, the design target, block type semantics, and diagonal behavior limits, which is far short of what this complexity requires.

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 eight required parameters that only have titles. The description only indirectly gestures at 'two points' (x1/y1/z1, x2/y2/z2) and 'block', and never mentions 'design' or the coordinate convention, so it does little to compensate.

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 what the output is ('a one-block line between two points, diagonal too') so an agent can infer this draws a line primitive. But it omits the verb and never says it places blocks into a design, which is what distinguishes it from siblings like box, cylinder, or sphere. Purpose is recognizable but vague.

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

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

There is no guidance on when to use this versus the other geometry siblings (box, cylinder, sphere, pyramid). 'Diagonal too' hints at a capability, not a usage condition, and no prerequisites or exclusions 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?

No annotations exist, so the description carries the disclosure burden. It usefully reveals that results are scoped to the current session and that each entry carries palette, size, and block count, but it never states that the operation is a read-only listing or how many designs may be 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 short sentence conveys scope and returned fields with no filler. It is front-loaded and efficient, though the verbless fragment style is slightly less actionable than an explicit 'List...' phrasing.

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 parameters and an output schema documenting the return shape, the description only needs to establish scope and content, which it does. The session-versus-saved distinction is implicit rather than spelled out, a minor gap.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify beyond the schema. Baseline 4 applies for a correctly parameter-free definition.

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 the resource (designs open in this session) and the exact fields returned (palette, size, block count), which distinguishes it from siblings like new_design or open_schematic. It lacks an explicit verb, but the noun phrase is unambiguous about what the tool enumerates.

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 alternatives such as open_schematic or new_design. The phrase 'in this session' hints at the scope, but the agent is left to infer that this is the enumeration step before opening or modifying a design.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes returned data fields but does not state that the operation is read-only, whether the design must already exist, what errors may occur, or any other behavioral traits; additionally, an output schema exists, so the return-content detail largely duplicates structured data.

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

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

The description is a single, front-loaded sentence with no filler. Every phrase contributes to explaining what the tool returns, making it highly concise and structurally efficient.

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

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

The tool is simple with one required parameter and has an output schema, so the description does not need to explain return structure in detail. However, it leaves the `design` input ambiguous and offers no usage context, so it is only minimally complete for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented `design` parameter. It only refers to 'the design' in passing and gives no meaning, format, or accepted values for the parameter, leaving the agent to infer whether it is a name, ID, or schematic reference.

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

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

The description clearly indicates that the tool reports the materials needed to build a design, including blocks, counts, stacks, tier, and highest tier. It is specific about the resource and output content, though it lacks an explicit verb and does not differentiate itself from siblings such as palettes or export.

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

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

There is no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The closest thing to guidance is the implied purpose of retrieving material requirements for a design, but that is not usage guidance beyond restating the tool's function.

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

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

No annotations exist, so the description carries the full burden; it does disclose the naming charset and that the name becomes the blueprint id, which is useful. It is silent on the important behavioral question of what happens if a design with that name already exists (error vs. overwrite) and on palette validity.

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

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

A single front-loaded sentence with no filler; the parenthetical constraint is placed right after the parameter it constrains. Slightly dense, but nothing is wasted.

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

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

An output schema exists so return values needn't be explained, which helps. Still, for a creation tool with zero annotation coverage the description omits collision behavior, palette valid values, and relationship to sibling tools, leaving 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. It does add real meaning for `design` (lowercase letters, digits, _ . -; becomes the blueprint id), but `palette` gets no semantics at all beyond the schema's default of 'oak' — valid values and their source are 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 verb+resource pair ("Starts an empty design") is specific and distinguishes it from read-oriented siblings like list_designs and open_schematic. It stops short of explicitly naming which sibling to use when creating vs. opening a design, 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?

Usage is only implied: 'starts an empty design' suggests the creation path, but the description never says when to pick this over open_schematic or how it relates to set_palette / palettes. No exclusions or prerequisites 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, and it does disclose one genuinely useful behavioral trait: blocks are loaded 'as they are (no roles)', i.e. no semantic role assignment is applied. It says nothing about whether an existing design is overwritten, what happens on a bad/missing path, or whether session state changes.

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

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

A single compact sentence with the verb and the file format front-loaded; nothing is wasted. The trailing parenthetical is slightly awkward but earns its place by conveying the no-roles 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 this is a simple two-parameter ingestion tool. Still, for a state-changing open operation with zero annotation coverage, the missing treatment of the 'design' parameter and of failure/overwrite behavior 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 description coverage is 0%, so both parameters are bare. 'path' is inferable, but the optional 'design' argument is entirely unexplained — the description's 'as a design' is ambiguous about whether it names the target design or just describes the result. 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?

Specific verb ('Opens') plus specific resource type ('.litematic file') and the outcome ('as a design to change'), which clearly distinguishes it from new_design or list_designs without naming them. A reader immediately knows this ingests an external file into the design workspace.

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 'as a design to change' hints at the editing workflow, but there is no explicit when-to-use, no prerequisites (does the file need to exist on disk? what paths are valid?), and no comparison against new_design or list_designs. The agent must infer the routing decision entirely.

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, yet it never says whether this is a read-only lookup, whether it reflects current state, or how much data is returned. The phrase "the block each role builds as" marginally implies preset/configuration data, but that is inference, not disclosure.

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

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

It is short and front-loaded, so nothing is wasted, but it is a sentence fragment rather than a self-contained statement of purpose. Brevity here comes at the cost of clarity rather than from 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?

The output schema covers return values, so the description needn't explain them. However, for a zero-parameter query tool with no annotations, the description still leaves the core question open: what does calling it do? That gap is not compensated elsewhere.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter information is missing or needed.

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

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

"The palettes, by tier, with the block each role builds as" is a noun phrase restating the tool name; there is no verb indicating what the tool does (list, look up, return). It hints at content structure (tier grouping, role-to-block mapping) but never states the operation, and does nothing to separate it from siblings like materials or set_palette.

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, when-not-to-use, or alternative is mentioned. An agent has no signal whether this is the way to discover palette data versus calling materials or open_schematic.

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 rendering quirks ('Colours are guessed from block names; glass is see-through') and view orientations, but it does not explicitly state that the operation is non-mutating, nor does it clarify the return format (image data, URL, etc.).

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 compact and every clause conveys useful information, especially the view definitions and rendering caveats. The first sentence is dense and slightly run-on, but it is reasonably front-loaded.

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

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

For a 3-parameter tool with no annotations and no output schema, the description gives enough to understand view/y behavior but leaves the required 'design' input and the exact return format unclear. An agent can infer a visual preview but lacks confirmation of how the design is specified and what is returned.

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 effectively defines the undocumented 'view' enum values with orientation details and explains that 'y' applies to 'layer' mode and is counted from the bottom. It omits any explanation of the required 'design' parameter, which keeps it from 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?

The description states that it produces 'A picture of the design' and enumerates view modes, so the resource and output are clear. It does not explicitly name the action (e.g., 'render' or 'generate'), and it does not distinguish itself from siblings like export or open_schematic.

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

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

There is no guidance on when to use this tool versus alternatives such as export or open_schematic. The description only explains view options, leaving tool selection entirely to inference.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It says nothing about whether existing blocks are overwritten, what 'hollow' changes structurally, how 'block' and 'design' affect placement, or any limits. For a mutation tool this is a substantial gap.

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

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

Two tight sentences that front-load the geometry definition before the secondary roof-use note. No filler, though the roof sentence is slightly tangential and not essential to correct invocation.

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 return values, and the core footprint/height geometry is explained. But for an 8-parameter mutation tool with no annotations and zero schema coverage, the unexplained block/design/hollow parameters leave the definition only minimally sufficient.

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

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

Schema description coverage is 0% across 8 parameters. The description clarifies x1..x2 and z1..z2 as the footprint and y as the starting height, but leaves block, design, and hollow entirely unexplained, so half the required surface is undocumented 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 specifies the exact geometric output (a stepped pyramid over a rectangular footprint from height y, tapering one block per side per layer). This clearly distinguishes it from siblings like box, cylinder, and sphere. It lacks an explicit verb like 'builds' but the shape 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?

'Also good for a stepped roof' gives one contextual use case, hinting at when the shape is appropriate. However, there is no guidance on when to prefer box or cylinder instead, no prerequisites, and 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?

No annotations are provided, so the description carries the full burden, yet it never says this is a destructive bulk mutation that overwrites existing blocks, whether it is undoable, or what happens to blocks that partially match. Only the state-matching behavior 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?

A single tight sentence with the core action front-loaded and no filler. It is perhaps too terse for the amount of undefined terminology ('role', 'design'), but nothing is redundant.

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

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

The output schema covers return values, and the state-matching rule is a genuinely useful extra. But for a three-required-parameter destructive mutation with zero annotation and zero schema-doc coverage, key facts (undoability, scope of 'every', design identification) 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%, so the description must explain all three required parameters. It gives partial meaning for 'old' (matching all states when no state is specified) but says nothing about 'new' versus 'old' formats or what the required 'design' parameter refers to (ID, name, handle).

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 verb 'Swaps' is specific and the object ('every old block or role for new') is identifiable, distinguishing it from set_block (single assignment) and clear (removal). It stops short of naming the design/schematic context the way a 5 would, but an agent can still place it among the siblings.

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

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

There is no statement of when to use this versus set_block, copy, clear, or symmetrize, and no prerequisites or warnings. The note about block names without state is a matching rule, not guidance about tool selection.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It says the tool mutates the world, but it does not disclose overwrite behavior, required permissions, coordinate semantics, failure cases, or what happens when setting to air.

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 definition is a single front-loaded sentence with no wasted words. However, it is too terse for a five-parameter mutation tool, so conciseness comes at the cost of under-specification.

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

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

An output schema exists, so return values need not be described. Still, for a five-parameter mutation tool with no annotations and no parameter descriptions, the definition omits critical context about design, coordinates, and replacement behavior.

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

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

Schema description coverage is 0%, and all five parameters are required. The description adds only a small clue about the block parameter's accepted forms, leaving x, y, z, and especially design 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 states a specific verb and resource: it puts one block, and it clarifies that the block may be a role, block state, or air. This is clearer than a tautology, but it does not distinguish the tool from nearby siblings such as replace or box.

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 set_block versus alternatives like box, line, replace, or clear. The only implied usage is placing a single block, with no exclusions or prerequisite 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, and it does disclose one real behavioral trait: 'literal blocks stay as they are', which tells the agent what is preserved. It does not say whether existing role assignments are overwritten, whether the change is undoable, or what the response contains, so the safety profile remains 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?

A single front-loaded sentence with no filler; the preservation clause is attached economically. It is terse rather than padded, though the terseness shades into under-specification.

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

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

An output schema exists so return values need not be described, but for a two-parameter mutation with zero schema description coverage and no annotations, the description leaves too much unresolved: parameter identity/format and the effect on pre-existing roles. An agent could not reliably call this 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% for both required parameters, so the description must compensate. It implicitly identifies `palette` as the source of the mapping and `design` as the target, but never says whether either is a name, an ID, or an index, nor what makes a palette valid.

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

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

The verb-and-resource pair ('Builds the design's roles from another palette') signals an assignment/mapping operation on a design, which is more than a restatement of the name. But 'roles' is unexplained domain jargon and it doesn't clearly separate this from siblings like `palettes`, `materials`, or `replace`, which plausibly overlap.

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 usage cue is the fragment 'such as a late-game one', which hints at when a particular palette is appropriate. There is no statement of prerequisites (must the palette exist?), no when-not guidance, and no alternative tool named for the related tasks a user might actually want.

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

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

Since no annotations are provided, the description performs the function of behavioral transparency by detailing the structural behavior of the 'half' parameter, specifically defining 'top' as a dome and 'bottom' as a bowl.

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 highly concise, using only two sentences to define the object's core geometry and the structural constraint of the 'half' parameter efficiently.

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

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

The description is incomplete because it only addresses positioning and the structural type ('half'), omitting contextual clues for other required parameters like 'design', 'block', or 'hollow'. It fails to provide the necessary comparison or usage context needed to select this tool over similar geometry functions.

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?

Given the 0% schema description coverage, the description adds crucial meaning to the spatial parameters (x, y, z) and structural parameter ('half'), which is vital for the agent's understanding of the required inputs.

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

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

The description clearly defines the resource as a ball centered at specific coordinates (x, y, z). However, it lacks a strong active verb and fails to distinguish the sphere from other geometric shapes listed among its siblings.

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

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

There is zero guidance on when to use the sphere tool versus alternatives like 'cylinder' or 'box'. It only addresses a specific feature of the 'half' parameter.

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 asymmetry-handling behavior (low side mirrored onto high side) and the default center, but it does not explicitly state whether the high side is overwritten, whether the design is modified in place, or what permissions/conditions are required.

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

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

The description is two tight sentences with the core operation and direction front-loaded, followed by the essential default behavior for center. No sentence 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. However, for a 3-parameter mutating tool with no annotations and 0% schema description coverage, the description leaves gaps around design input format, overwrite behavior, and exact axis values.

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 clarifies the semantics of axis via the x/z plane and explains that center is the plane's coordinate with a default of the design midpoint, but it does not describe what the design parameter expects or give explicit axis values.

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 operation on a specific resource: making a design symmetric across a plane, with the low x/z side mirrored onto the high side. This clearly distinguishes it from all listed siblings, none of which perform symmetry operations.

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 operation implies when it would be used—when a design should be made symmetric—but there is no explicit guidance on when to choose this over alternatives, prerequisites for calling it, or when not to use it.

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

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

With no annotations, the description carries the full disclosure burden. It hints at a bounded history ('up to 20') but never states permissions needed, behavior when history is exhausted, whether it is per-design, or that it mutates state — all of which matter for an undo 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?

One short sentence, front-loaded with the core action, with no filler. It is slightly cryptic rather than verbose, but nothing is wasted.

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

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

An output schema exists so return values needn't be explained, but for a mutation tool with zero annotations the description is too thin — nothing on the required design argument, failure modes, or scope of what gets reverted.

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

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

Schema description coverage is 0% and the single required parameter 'design' is undocumented in both the schema and the description. The agent cannot tell whether 'design' is an ID, a name, or an open-document handle.

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 effect: takes back the last change. This is clearly distinguishable from siblings like clear (wipes state) or replace, though the parenthetical '(up to 20)' is ambiguous about whether it is a history limit or a batch capability.

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 undo versus alternatives such as clear or replace, and no prerequisites (e.g., an open design with existing history). The agent must infer the applicable context from the name alone.

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