wafeq_item_units_of_measure_retrieve

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds no contradictions—just reinforces READ-ONLY and provides the GET path. It does not add meaningful behavioral context like error cases or preconditions, but the annotations carry the safety profile well.

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 endpoint header is compact and front-loaded, but the following two sentences ('Retrieve item unit of measure' and 'Endpoint for retrieving a single item unit of measure') restate the same operation. A single merged sentence would carry the same information with less redundancy.

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 single-parameter, read-only retrieve operation with rich annotations, the description together with the schema is largely sufficient. The endpoint, resource, and single-item scope give an agent enough to select and invoke it; only output-shape details are absent, which is acceptable given no output schema and the simple resource type.

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 only provides a required id string with 0% description coverage. The endpoint template shows that id is a path identifier, which partially compensates, but the description does not explain where the id comes from, its format, or any constraints beyond the 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 a specific verb and resource: retrieving a single item unit of measure via GET /item-units-of-measure/{id}/. It is unambiguous for the retrieve operation, though it does not explicitly differentiate from the similarly named units_of_measure_retrieve sibling.

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 phrase 'retrieving a single item unit of measure' implies this tool is for fetching one record by id, which gives some usage context. However, there is no explicit when-to-use or when-not-to-use guidance, and no reference to list/create/update alternatives.

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