place_on

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

Annotations declare destructiveHint=true, openWorldHint=false, readOnlyHint=false, so the mutation risk is known. The description adds ray-based placement semantics and that children move with the object. However, it omits side effects like parent/ transform changes, whether it constitutes a mutation on existing transforms, and does not address the destructiveHint in a way that goes beyond the annotation.

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 dense but front-loaded with the core operation before the alternatives. It splits into two sentences: mechanism then routing. No gratuitous filler, though the second sentence is a bit of an enumeration that could be tighter.

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 4-parameter mutation tool with no output schema and 0% schema coverage, the description should fully compensate for missing parameter docs. It explains the core operation and mentions alternatives, but leaves the meaning of yaw_deg and the surface list format to inference. Complete enough for the general behavior but not for all parameters.

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

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

Schema description coverage is 0%, so the four parameters (at, object, surface, yaw_deg) are undocumented in both schema and description. The description mentions 'object', 'surface' conceptually, and 'world xy at', and mentions yaw only indirectly ('drop by a ray' does not explain yaw_deg). It does not explain surface as a list of strings or the format of at. This leaves the parameters underspecified.

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 precise verb and mechanism: 'Drop by a ray: lower an object (with children) until its lowest point lands on the first surface under it.' It clearly distinguishes from siblings by naming ground, attach, and scatter with their specific semantics.

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 explicit when-to-use examples ('props on tables, floors with height changes, terrain') and explicitly steers away to alternatives: 'Use ground for a level floor at a known height, attach to align by bounding boxes, scatter for many copies.'

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