competitor_price_index

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds that this is an aggregate per-SKU comparison producing an indexed score versus a target band, but it says nothing about how SKUs outside a band are treated or what the computation needs to run.

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?

A single front-loaded sentence with no filler; the comparison logic and the target-band criterion both earn their place. It is arguably too terse for a tool whose only parameter is undocumented, but there is no structural waste.

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 an output schema present and read-only annotations, return values and safety need no explanation. However, the required `category` argument and the scope of 'each SKU' (all products in that category?) are left unstated, leaving the agent under-informed before invocation.

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 0% and the single required parameter `category` is never mentioned in the description. The agent must guess whether it is a product category, a filter scope, or an enum-like value, so the description does not compensate for the schema gap.

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 names a specific verb (compare) and a precise comparison basis: each SKU's price vs. the median competitor price, evaluated against its tier's target band. That is enough to distinguish it from siblings like check_price_ladder or check_price_guardrails, though it never states the scope the required `category` argument implies.

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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as check_price_ladder or get_price_elasticity. The phrase 'against its tier's target band' hints at context but leaves the agent to infer when this analysis is the right call.

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