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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds no behavioral context beyond the filter list — nothing about result limits, how 'no results' behaves, whether filters combine with AND semantics, or how the data source is scoped. It adds some value (the enumerated filterable dimensions) but the behavioral burden is largely carried by annotations and schema.

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 sentence is well front-loaded, but the second half is a bloated trigger-phrase list with near-duplicates ('Shopify product query', 'shopify items', 'Shopify products'). Roughly half the text is keyword stuffing rather than information, which dilutes rather than earns its place.

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 16 optional parameters and no output schema, the description should at minimum characterize what comes back (fields, pagination totals) and how filters combine. It covers the input dimensions adequately but leaves the output side entirely implicit, which is a real gap for a tool with no return-value documentation.

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 parameter including page, pageSize, sortBy default 14, and the min/max range pairs is already documented. The description restates the same dimensions without adding semantics the schema lacks, such as how competitionMin/competitionMax interact or what valid sortBy enumerations exist. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Filter Shopify standalone store products') and enumerates the filterable dimensions (price, weekly sales, listing date, Facebook ads, competition, supplier availability, shipping country). This clearly separates it from nexscope_shopify_store_query, though the sibling is never named as the counterpart. It is clear but relies on the grader knowing the sibling set to fully disambiguate store-level vs product-level queries.

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?

Usage is spelled out through a long trigger list ('whenever searching for products, viewing weekly sales/revenue/competitiveness, or filtering products on Shopify standalone stores'), which gives the agent explicit activation conditions even without the tool name. What's missing is negative guidance: it never says when NOT to use it, e.g. that Amazon/Etsy/Temu product searches or store-level lookups belong to other tools.

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