omni_shape_hollow_box

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

With no annotations at all, the description carries the full behavioral burden. It meaningfully discloses that the tool expands into up to 6 fill_area operations, which informs the agent about world-modifying side effects and scale. However, it does not state whether existing blocs are overwritten, what happens when toggles are off, or any preconditions and permissions—gaps that matter for a mutating shape tool.

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

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

Two short sentences with zero filler: the core purpose and mechanism are front-loaded in sentence one, and the distinctive togggable-face behavior is in sentence two. Every word earns its place without repetition of schema property names or types.

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 7-parameter tool with no annotations, no output schema, and no schema parameter descriptions, a two-sentence description is insufficient. An agent cannot fully resolve the meaning of block and meta, is not told the tool overwrites world state, and gets no guidance on edge cases (e.g., from == to or all faces disabled). The core shape concept is covered, but the operational essentials are not.

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 compsensate. It adds real meaning to three booleans (floor/ceiling/walls = independently togggable faces), which maps directly to the schema. But it says nothing about the required from/to coordinates beyond what the name implies, and block and meta (an unexplained 0-15 integer) are completely undocumented anywhere—a serious gap at 0% schema coverage.

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

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

The description identifies a specific resource ('Hollow cuboid shell') and a concrete mechanism ('as up to 6 fill_area ops'), clearly distinguishing this from the sibling omni_shape_solid_box. The verb is only implicit rather than explicitly stated (e.g., 'creates')—hence not a 5—but there is no ambiguity about what this tools does.

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

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

The togglable floor/ceiling/walls strongly imply this tool is intended for hollow structures where faces can be selectively enabled, but no explicit when-to-use vs alternatives is given. The description never names omni_shape_solid_box or any sibling as the alternative for filled cuboids. Usage must be inferred from the name and wording rather than being stated directly.

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