WB Buyer Questions by imt_id

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds substantial behavioral details beyond those: an empty pool is not an error, pagination happens in pages of 30 (upstream cap), and a full error format section covers BadRequestError, RateLimitedError, TransportDownError, and ParserDriftError. It also explains the pooling behavior across variants and the nmId empty-pool consequence.

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 longer than average but well-structured with sections for main purpose, context, return format, and error format. It is front-loaded with the essential purpose and keying detail. No sentence is redundant; each adds value, but the error format section could arguably be summarized since the output schema exists. Still, it is appropriately scoped for the tool's complexity.

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?

Given the tool's complexity (imt_id vs nmId, shared pool, pagination, empty pools, error cases), the description covers all necessary context: return format, error format, parameter semantics, and behavioral expectations. The output schema handles return structure details, and the description compensates for the schema's lack of runtime behavior. An agent can confidently invoke this tool correctly without additional lookups.

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 coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: imt_id is the root ID from wb_root_info and must not be an nmId; limit is 'Fetched in pages of 30'; answered_only is framed as a filter for product-relevant questions ('Unanswered questions carry no product information'). These clarifications help the agent select and construct correct calls.

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 starts with a clear verb and resource: 'Fetch buyer questions and seller answers by imt_id (root_id from wb_root_info).' It explicitly distinguishes this tool from wb_reviews: 'Reviews describe the experience of owning the product; questions clarify what it actually is.' The scoping to imt_id and the relationship to wb_root_info further solidify its unique role among siblings.

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 provides explicit when-to-use context: buyers ask about listing omissions, and seller answers are often the only public statement. It names an alternative (wb_reviews) and contrasts them. It also gives a clear prerequisite: 'resolve the root id via wb_root_info first' because passing an nmId returns an empty pool. The answered_only parameter guidance ('Unanswered questions carry no product information') tells the user when to use it.

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