set_dimension

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety bar is lower here. The description usefully adds that changes go through the native SOLIDWORKS engine and that geometry is expressed in mm/degrees/kg, plus that error evidence is returned. It does not disclose what a changed dimension does downstream (rebuild, broken features, references), which is the key risk for a destructive mutation.

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 short sentences with no padding, and the action is front-loaded. But the final sentence ("Inspect verified measurements and error evidence") is vague and imperative-sounding, reading like a leftover instruction rather than actionable guidance for the caller.

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?

This is a destructive mutation with two required parameters, no output schema, and no documentation of the input identifiers. The description omits the state model (requires an open part? active document?), what happens to dependent geometry after a change, and how to obtain a valid dimension_name - the essentials for invoking it correctly.

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 clarify the unit system (mm, degrees, kg), which resolves the tension of a parameter literally named value_mm accepting angular and mass values. However, it never explains dimension_name - whether it must match an entry from list_dimensions, a feature name, or a user-visible label - leaving half the parameters 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?

States a specific verb and resource ("Set dimension") and names the engine, but never says what a dimension is here - a sketch dimension, a feature parameter, a drawing annotation? A sibling named list_dimensions implies model dimensions, yet the description doesn't connect to it or scope which dimensions are settable. The agent knows roughly what happens but not precisely to what.

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 when-to-use guidance, no prerequisites (must a part be active? must the dimension exist first?), and no alternatives named despite list_dimensions being the obvious read-side counterpart. "Inspect verified measurements" hints at a follow-up verification step but never states the condition for doing so.

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