properties

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

With no annotations, the description carries the full burden. It discloses helpful behavioral details: unknown keys become custom properties, properties feed the BOM and title block, and mass_kg overrides mass for surface-only vendor models. But it omits key behavioral traits such as permission requirements, what happens when values is omitted or null, whether the operation is transactional, and how this relates to separate material/parameter tools.

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 front-loaded with the core action and scope, then organized into an Args section. It uses examples and rationale efficiently without unnecessary repetition. Minor verbosity in the mass_kg explanation is justified by the non-obvious behavior described.

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 complexity (read-write, 4 parameters, no annotations) and the presence of an output schema, the description is largely complete. It covers the purpose, parameter meanings, side effects on BOM/title block, and custom-property behavior. The remaining gaps—explicit read-only conditions and differentiation from set_material—are minor but prevent a perfect score.

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 only 25% (only instance is documented in the schema), so the description must compensate. It does so effectively: it explains values with an example and the custom-property behavior for unknown keys, clarifies material as a library name and points to list_materials, and gives a concrete use case for mass_kg override. The instance parameter is covered by the schema. This adds meaningful context beyond the bare schema.

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 clearly states that the tool reads and optionally sets the active document's iProperties, and it enumerates the specific properties covered (part number, description, stock number, vendor, revision, title, cost center, material, mass, custom). An agent can identify the core resource and operation, though it doesn't explicitly differentiate from the sibling set_material tool for the material field.

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 implies usage ('Read — and optionally set') and provides some guidance for material (referencing list_materials) and mass_kg (for vendor surface models, referencing material_report). However, it does not state when to use this tool versus alternatives like set_material, set_parameter, or get_parameters, nor does it clarify the read-only versus mutation conditions.

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