create_slab

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

With no annotations, the description carries the full burden and provides substantial behavioral detail: it explains the z-range calculation, the default top/floor level, the wall-outline fallback with outward margin, and the replace semantics. It leaves one notable behavior undocumented (the `view` parameter) but otherwise gives a strong picture of what the tool does.

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 dense sentences, each earning its place: the first defines the geometry source, the second defines vertical placement, and the third defines replacement behavior. No filler or repetition, and the core purpose is front-loaded.

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

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

Given the tool's geometric complexity and zero annotation coverage, the description is reasonably complete but has gaps: `view` is undocumented, units for `margin`/`thickness` are not stated, and the prerequisite that walls must exist when `points` is omitted is only implied. An agent could still invoke it incorrectly without this missing context.

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

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

Schema description coverage is 0%, so the description must compensate, and it covers most parameters: points, margin, top, thickness, and replace all receive meaningful explanations. Only `view` is left unexplained, which prevents a perfect score.

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

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

Description clearly states a specific verb ('create') and resource ('floor slab under the house'), and the 'under the house' context differentiates it from related tools like create_roof or create_wall_2d. However, it does not explicitly name or contrast any sibling tool, so it stops short of full sibling differentiation.

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

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

No guidance is given on when to choose this tool over alternatives such as create_roof, create_rectangle, or create_wall_2d. The only usage-related note, 'replace=false to add a second slab,' concerns parameter behavior rather than tool-selection criteria.

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