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

Annotations already cover the read-only, non-destructive, open-world profile, yet the description still adds meaningful context beyond them: it discloses that responses contain merchant PII (reviewer name, email, Shopify customer id, order id) and that status defaults to published rather than returning everything. It doesn't mention rate limits or pagination mechanics, which keeps it from a 5.

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?

Three dense sentences: scope first, returned payload second, filtering third, with the endpoint as a trailing implementation detail. No filler, and the most disambiguating information is front-loaded.

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 eight optional parameters, no output schema and annotations already carrying the safety profile, the description compensates by enumerating returned fields and default filter behavior, which is what an agent needs to interpret results. It says nothing about the pagination contract (next_page) or response envelope shape, a minor remaining gap.

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 all eight parameters, their enums and defaults are already documented in the schema; baseline 3 applies. The description reinforces that status defaults to published and that date filters hit createdAt, but it adds no syntax or semantics for sort, direction, page or limit beyond what the schema states.

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 ('List store-level reviews') and immediately disambiguates the scope with '(about the shop, not one product)', which is exactly the boundary against the sibling loox_list_product_reviews. It also names the returned fields and the underlying endpoint, so an agent knows precisely what it is calling.

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 parenthetical scoping note plus the filter summary (star rating, status defaulting to published, date range on createdAt) give a clear picture of when this tool applies versus the product-review siblings. It lacks an explicit 'use X instead when' statement and doesn't mention the summary/get variants, so it stops short of full routing guidance.

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