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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description goes further by disclosing that the response includes the account's private data (reviewer e-mail, order) and how pagination behaves ('Pages are 1-based; next_page is set when more results remain'), which an agent cannot infer from the annotations alone.

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?

It front-loads the key claim ('The recommended way to read reviews') and packs scope, filters, pagination and endpoint into three dense sentences with little waste. The middle filter-list sentence is long, but each clause corresponds to real capability rather than filler.

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?

With no output schema, the description partially compensates by describing the timeline contents, private-data inclusion and the next_page continuation signal. For a 16-parameter read tool it covers scope, filtering and pagination adequately, though it omits auth requirements and any sense of result volume or rate limits.

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 every one of the 16 parameters is already documented, making 3 the baseline. The description adds only a high-level synthesis of the filter dimensions plus two defaults ('newest-first by default', 1-based pages) that are also present in the schema, so it does not meaningfully extend parameter meaning.

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 states a specific verb and resource and enumerates the four review kinds it covers (company/store, product, third-party, questions), which lets an agent distinguish it from narrower siblings like list_company_reviews. It stops short of naming those siblings explicitly, so the differentiation is implied by 'the recommended way to read reviews' rather than spelled out.

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?

Calling itself 'the recommended way to read reviews' gives clear guidance to prefer this tool over the more specific list siblings, and the filter enumeration shows what it is for. There is no explicit when-not-to-use statement or named alternative, so it lands at clear-context-but-no-exclusions.

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