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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so well: it explains that the return is the offer itself (price, stock, specifications, product link), that specification matching works beyond model names, and that an empty result means 'not indexed, not nonexistent'. It stops short of describing response shape or sort edge cases, but for a search tool this is strong behavioral context.

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 description is four sentences, each earning its place: core action, usage distinction, specification-search behavior, and coverage caveat. The most important scoping information is front-loaded, and the text is dense without being bloated.

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?

For a tool with no output schema and nine parameters, the description covers the essential context: what it searches, how it differs from the sibling, what results contain, and how to interpret empty results. Minor gaps remain, such as an explicit statement of pagination/limit behavior and currency of prices, but those are partially covered by the schema and do not severely hinder correct use.

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 78%, so the schema already documents most parameters. The description adds real value beyond that for the `query` parameter: it clarifies that specifications are searchable and that queries like 'ноутбук 16 гб 512 ссд' match on capacity and features. It also adds coverage semantics relevant to interpreting results, which no parameter description captures.

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 opens with a specific verb and resource — 'Search shop catalogues' — and adds the key dimensions: name/specification querying, price/availability filtering, and price sorting. It also explicitly contrasts itself with the sibling tool `search`: 'search returns pages that mention a product, this returns the offer itself'. An agent can unambiguously tell what this tool does and how it differs from its sibling.

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 gives an explicit routing rule: 'Use this rather than `search` whenever the question is what something costs or where to buy it' and explains the distinction between offer-level and page-level results. This tells the agent both when to use this tool and when the alternative is appropriate. No further inference is needed.

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