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

Annotation contradiction: the description claims the operation 'Changes the quantity on hand of inventory items and books the valuation difference' while readOnlyHint=true declares the tool is read-only. The description does not clarify that these change semantics describe the inventory adjustment record itself, not the GET call. It does add the useful US Plus/Advanced eligibility constraint, but the contradiction is a critical failure.

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 first sentence is appropriately front-loaded and concise, but the second sentence is an ambiguous dangling fragment that introduces the annotation contradiction. Not every sentence earns its place, and the unclear subject structure is a readability problem.

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?

There is no output schema and the description does not describe what the GET returns. The read-only behavior is undercut by the contradictory second sentence, and although the US Plus/Advanced eligibility note is useful, the description is not complete enough for an agent to safely invoke the tool.

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 100%, so id and company are already fully documented in the JSON schema. The description adds only the eligibility constraint and no meaningful parameter semantics beyond what the schema already provides.

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 first sentence states a specific verb ('Get'), resource ('inventory adjustment'), and retrieval key ('by Id'), making it easy to distinguish from sibling create/update/delete and get-valuation tools. The second sentence is confusing but does not obscure the primary purpose.

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 no guidance on when to prefer this tool over alternatives, such as get_inventory_valuation_summary, get_physical_inventory_worksheet, or search tools, and does not state when not to use it. 'By Id' is already captured by the required id parameter and adds no real selection guidance.

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