ifc_set_placement

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

With no annotations, the description carries the behavioral disclosure burden. It usefully reveals matrix conventions: row-major, translation in the last column in metres, fixed bottom row. However, it does not disclose side effects such as whether the change is in-memory only, whether a save is required, or whether dependent geometry is updated.

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 three short sentences with no filler. Purpose comes first, followed by precise format constraints, then a practical hint for retrieving the current matrix. Every sentence 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?

For a two-parameter mutation tool with no annotations, the description explains the purpose and matrix format well, and an output schema covers return values. Still, it omits operational context such as whether the model must be open, whether changes persist only after ifc_save, and whether setting an absolute placement recomputes dependent geometry. These gaps make it solid but not fully 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?

The input schema has no parameter descriptions (0% coverage), so the description must compensate. It does so strongly for the matrix parameter: 4x4, row-major, translation in the last column in metres, bottom row [0, 0, 0, 1]. The guid parameter is only implied as the element identifier, but the critical matrix semantics are clearly documented.

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 and object: 'Set an element's absolute 4x4 placement matrix.' The word 'absolute' clearly distinguishes this from relative transform siblings like ifc_move_element and ifc_rotate_element, so an agent can tell the intent without opening schemas.

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 a clear sequencing hint ('Get the current one from ifc_geometry_info') and implies this is for absolute placement, but it never explicitly states when not to use this tool or names alternatives for relative movement/rotation. Usage context is present but mostly implied rather than stated.

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