Get parts list

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

The annotations say readOnlyHint=false and openWorldHint=false; the description is consistent with that by disclosing that the `board` parameter 'switches the board first,' which explains the non-read-only side effect. It also describes the returned contents, though it does not clarify default/current-board behavior when `board` is omitted.

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 'Bill of materials' and most of the long first sentence is substantive detail about returned parts and fields. It is somewhat sprawling due to the long parenthetical and list, but it does not waste many words on irrelevant material.

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, so the description usefully enumerates the return contents: quantities, approximate THB prices, shop links when known, and a plain-text copy list. It also discloses the board-switching side effect. The main remaining gap is what happens when the optional `board` argument is not supplied.

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?

With one optional enum parameter and 0% schema description coverage, the description carries the burden and does add meaning: `board` switches the board first, and the accepted values are 'esp32', 'uno', or 'raspberrypi'. It repeats the enum values but also explains the parameter's side effect; only the default behavior when omitted is left unstated.

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 identifies a specific resource, the rover's bill of materials, and enumerates its scope: board, motor driver, sensors, display, camera, head servo, chassis, battery, buck converter, resistors, level shifter, quantities, prices, shop links, and a copyable plain-text list. This is far more specific than a name/title restatement and clearly distinguishes it from generic manifest, sensor, or wiring tools.

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?

It gives clear usage context by tying the tool to 'building the fitted rover body for real' and 'the parts tab on the Wiring page.' It does not explicitly name alternatives such as get_manifest or get_wiring, but the context is strong enough for an agent to know when this tool is appropriate.

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