cvs_product

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

With no annotations, the description carries the behavioral disclosure burden. It handles this well by explaining the OTC-only scope, the slug/URL formats accepted, the US/territory geographic restriction, and the fact that unsupported regions return an upstream error rather than empty results. It does not mention read-only semantics explicitly, but the nature of a product-detail lookup makes that clear enough.

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 largely efficient and front-loaded: it starts with 'CVS OTC product detail' and then expands. Very little is wasted, though the first sentence and the second sentence both restate the same basic purpose, creating slight redundancy. The rest of the details, especially the slug explanation and geographic note, earn their place.

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 a single parameter and no output schema or annotations, the description covers the important operational context: what fields are returned, what catalog is covered, the exact input format, and the expected error behavior for unsupported regions. It could add explicit not-found behavior, but for this low-complexity case the description is reasonably complete.

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, slug, is described in the schema as a simple 'CVS product page URL slug' with a cut-off example. The description adds substantial value by precisely defining what the slug is (the segment after /shop/), giving a concrete example, and noting that a full URL is also accepted. This goes beyond the bare schema and makes correct invocation likely.

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 states the tool's verb and resource: it returns one CVS OTC product's detail, enumerating fields like name, brand, price, and aggregate rating. It also sets boundaries (OTC retail only, not prescriptions). However, it does not explicitly differentiate itself from sibling tools such as cvs_search or cvs_product_ingredients, leaving the agent to infer the difference.

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 clear context: it is for a single CVS OTC product, requires a slug or full URL, and it explicitly excludes prescription items and patient-specific data. It also mentions the US-egress requirement. It stops short of naming alternatives for search or ingredient lookups, so it is not a full 5.

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