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

Annotations already flag this as a non-read-only, non-idempotent write, and the description adds two genuinely non-obvious behaviors: the bid must exceed the current high bid, and the response never discloses reserve status before close. It does not cover whether bids are binding/escrowed or how an under-bid failure surfaces, but the reserve caveat is exactly the kind of detail annotations cannot carry.

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 definition is short, front-loads the action and the WHEN condition, and every clause carries information. The opening sentence largely repeats the name/title, which is the only wasted line.

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 write tool with full annotation coverage, a 100%-documented 4-parameter schema, and no output schema, the description covers the essentials: whose auction, what counts as a valid bid, and the key expectation gap about reserve disclosure. No material information needed to invoke it correctly is missing.

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 100%, so the baseline is 3, and the description earns the step up by adding a real constraint on the bid amount that the schema does not state (must exceed the current high bid). The example clarifies auction_id usage, though the amount/amount_usd alias relationship is left to 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 uses a specific verb and resource ("Place auction bid") and narrows scope to a cash bid on an open auction, which separates it from auction_close and auction_status. It stops short of naming a sibling explicitly, so it lands at a clear 4 rather than a 5.

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 "WHEN:" clause states the triggering condition plainly: a cash bid on an open auction. It gives no when-not guidance (e.g., what to use for barter offers, or what to do once an auction has closed), so it is clear context without exclusions.

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