peek_stores

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal several traits: the call is 'quiet', should happen once, should not list SKUs, and should use sayToUserRu. However, it never explains what output the tool produces, whether it makes an external request, or what 'owner agrees' means, leaving key behavior implicit.

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 short and every fragment is an instruction, which avoids bloat. But phrases like 'Quiet first hop' and 'Speak sayToUserRu' are unexplained jargon, and the compressed style sacrifices clarity for brevity. It is not too long, but it is cryptic enough that an agent may struggle to interpret the intended behavior.

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 single-parameter tool with no output schema, the description gives enough invocation constraints to avoid obvious misuses, such as calling search_products too early or answering advice requests. Yet it never explains what peek_stores actually accomplishes or what the agent should do with its result, so the chain from this tool to later steps is vague. The low parameter count keeps this gap moderate rather than severe.

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?

The only parameter need is already fully documented in the schema with an example ('Topic, e.g. техника, витамины'), so the baseline is 3. The description only repeats 'Pass need' and adds no new semantics about value format, constraints, or phrasing. The schema covers the parameter, but the description does not enrich it further.

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 reads as usage policy more than a definition: it lists trigger phrases and tells when to call, but never states what peek_stores actually does or returns. 'Quiet first hop' and 'Do NOT list SKUs' hint that it is a preliminary store-level lookup, but the core verb+result is left implicit. This makes the tool's function hard to state precisely from the description alone.

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?

This is the strongest dimension. It gives explicit trigger phrases, a once-per-conversation rule, a clear exclusion ('Never call for advice'), and a named alternative with a condition ('Do NOT call search_products until the owner agrees'). It also instructs to pass the need parameter and to respond via sayToUserRu.

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