Comparar cadenas

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

With no annotations, the description carries the full burden and does so richly: it warns that each chain resolves items independently so 'cheapest' may be a different product/format, tells the agent to use the `comparability` field and to compare price-per-unit rather than total, and discloses partial-failure behavior ('si una cadena falla, se reporta y las demás siguen') plus the tottus/lider browser-bridge constraint.

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?

Front-loads purpose, then a highlighted caveat, then the secondary capability and a note. It is dense but each clause carries information (comparison caveat, alternative tool, chain availability, failure handling); slightly long for the tool's scope but not padded.

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?

There is no output schema, so the description must cover return values, and it does reasonably ('Devuelve por cadena el mejor match por ítem y el total' plus the `comparability` field). Failure handling and the browser-bridge dependency fill the remaining gaps, leaving only exact response formatting unspecified.

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 100% and both the free-text items list and the stores enumeration are fully documented there. The description's references to `comparability` concern the output rather than a parameter, so it adds minimal meaning beyond the schema; baseline 3 is appropriate.

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?

States a specific verb+resource: it estimates the total of one free-text list across several Chilean chains and flags the cheapest among those carrying all items. It also distinguishes itself from the sibling build_list by framing comparison as the core job and build_list as the day-to-day alternative.

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?

Explicitly routes daily-use cases to build_list and explains that tottus/lider are only included when the browser bridge is configured. It gives clear context and a named alternative, though it does not state a hard exclusion for when compare_stores should not be used.

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