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

Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the bar is lower; the description still adds real substance by disclosing the rate formulas, the $1,000 per-sale minimum, and that rates are posted rather than locked. It does not describe pagination or result granularity, but the output schema exists to carry that.

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 core scoping sentence is front-loaded and useful, but the closing "Read-only; posted rates, not a locked quote" repeats both the readOnly annotation and the earlier "Posted rates, not locked quotes" clause nearly verbatim. Removing that tail would cost no information.

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 3-optional-parameter read tool with a full output schema and rich annotations, the description supplies the pricing basis, the minimum-sale constraint, and the when-to-call cue. What remains unstated — how results are shaped per item, or what an empty result means — is acceptably delegated to the output schema.

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% (metal enum documented, search example "Maple Leaf", product accepts id/slug/URL), so the schema does the work. The description only echoes the metal set when explaining rate formulas and adds no lookup syntax or combination rules, making 3 the correct baseline.

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?

States a specific verb and resource — what Bullion Trading LLC pays when you sell bullion back — and quantifies the pricing model per metal (spot bid minus 3% or 5% for gold/platinum/palladium; minus $3 or $5/oz for silver). That pricing detail is enough to distinguish it from siblings like get_spot_prices and get_premiums without opening their schemas.

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?

"Use when the user asks what Bullion Trading LLC pays to buy an item back" gives an explicit trigger condition, and the $1,000 minimum per sale implicitly bounds when the answer applies. No alternative tool is named for adjacent questions (e.g. current spot prices or premiums), so the routing guidance stops just short of a 5.

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