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

The annotations already declare this a safe, idempotent read, so the bar is lower, and the description still adds real behavioral context: it is free/non-billable, freshness is per-signal, price freshness includes the share of priced products read in the last 7 days, and large catalogs are sampled with records_approximate flagged. That sampling caveat in particular is behavior an agent could otherwise misread as incomplete 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 purpose is front-loaded correctly, but the middle sentences are densely nested parentheticals ('records counts products, each product once however many variant rows it has; for large catalogs these come from a sample and are marked records_approximate') that require re-reading. The information is worth keeping, but the packaging is heavier than needed.

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 has to convey the return shape, and it does: per-signal availability plus freshness, record counts with an approximation flag, and the definition of 'available'. What it lacks is any sense of the full signal list or what a negative result means for the agent's next step, which keeps it short of a 5.

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?

There is a single parameter with 100% schema description coverage ('eCommerce domain, e.g. gymshark.com'), so the schema already carries the semantics. The description adds no format, normalization, or failure guidance for the domain argument (e.g. what happens on an untracked domain), so baseline 3 applies.

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 ('Check which competitive signals RivalSweeper has for an eCommerce domain') and makes the scope explicit: this is a coverage/pre-flight probe, not a data fetch. The clause 'A signal is available exactly when its tool has data' ties it to the sibling tools it gates, so an agent can separate it from get_brand_price_statistics or get_active_promotions_and_coupons.

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 implies the intended workflow by mapping signals to the tools that return them ('promotions counts the live offers get_active_promotions_and_coupons returns, prices follow get_brand_price_statistics'), and 'Free and non-billable' is a useful selection lever. However, it never states outright when to call this versus those tools (e.g. 'call this first to confirm data exists before spending a billable call'), leaving the agent to infer the ordering.

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