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, but it only lists content categories and says nothing about side effects, read-only status, result behavior, or pagination. It does not contradict the name's implication of a search operation, but it adds no meaningful behavioral transparency beyond the category list.

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 extremely concise and wastes no words; every listed item adds useful context. It is a fragment rather than a complete sentence, but its compact structure makes the domain scope immediately scannable.

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 annotations and no output schema, the description is too skeletal to be a complete guide. An agent is left without an explicit statement of what the tool returns, how the query behaves, or what product_ids does. The category list is helpful but insufficient for confident 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%, so the description must compensate for parameter meaning. It partially does by providing a vocabulary for the 'query' parameter (e.g., refunds, cancellation, delivery). However, it does not explain the optional 'product_ids' parameter or how it interacts with the search, leaving a significant 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 clearly identifies the resource domain as storefront policies, enumerating specific categories such as refunds, cancellation, delivery, and privacy. Although it lacks an explicit verb, the tool name 'search_policies' supplies the action, and the topic list distinguishes it from sibling tools like search_products.

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 list of policy topics provides implied usage context: an agent would know to use this tool when a user asks about refunds, cancellation, delivery, or similar storefront policies. However, there is no explicit guidance about when not to use it or how it compares to alternatives such as search_products.

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