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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: the record is 'observed' rather than live (with 'first/last-observed timestamps' signaling possible staleness), reviews are capped at 'max 12' and are opt-in 'to keep the payload small,' and the scope is restricted to 'Amazon marketplaces only.' These traits materially affect how an agent interprets the data.

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 information-dense and front-loaded with the core resource, with each sentence earning its place: return-contract enumeration, the reviews opt-in behavior, and usage routing. It loses a point only for minor redundancy — the usage sentence ('description, bullets, images, categories, variations') largely restates the field list already given in the opening sentence.

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 simple 3-parameter read tool, the description is nearly complete. With no output schema present, the detailed field enumeration serves as the return contract and is comprehensive for both the base record and the appended reviews. Remaining gaps are minor: it does not address error/edge cases such as an ASIN with no observed record yet, or whether the 'observed' nature means data may be stale.

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% — all three parameters (asin, marketplace_id, include_reviews) have descriptions in the schema, so the baseline is 3. The description adds genuine meaning above the schema by specifying exactly what include_reviews=true appends (author, rating, title, trimmed text, verbatim date, verified flag, helpful votes) and explaining the payload-size rationale behind the default-false choice, which the schema does not convey.

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 specifies an exact resource — 'the observed page-content record for one Amazon ASIN' — and enumerates its full contents (description with source type, feature bullets, breadcrumb path, image-gallery URLs, variation count + parent ASIN, stock state, timestamps). This field-level enumeration makes it instantly distinguishable from siblings like asin_buybox_history, asin_profit_calc, and asin_comparables, which target price history, profitability, and comparable products respectively.

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 explicit when-to-use guidance: 'Use when the user asks what a product's page says or shows — its description, bullets, images, categories, variations — or wants the reviews on a listing.' This is clear context, though it never names sibling alternatives or states when NOT to use this tool (e.g., price history → asin_buybox_history), so it stops short of a full routing matrix.

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