auditar_cluster

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

The description adds behavioral context by stating the DYNAMIS rule for resource prioritization (close ★ first, then ◇) and indicates the tool is used for ongoing processes. However, it does not explicitly state whether the tool is read-only or has side effects, and there are no annotations to compensate. Given the lack of annotations, the description should more clearly disclose safety characteristics.

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 concise at three sentences, front-loading the key output (checklist) and rule, then ending with the use case. Every sentence adds value without redundancy, making it efficient and easy to parse.

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 covers the purpose, an important behavioral rule, and the use case. It does not describe the exact return format beyond the symbols, but the separation into ★ and ◇ gives sufficient insight. Some examples of usage or error conditions could improve completeness, but it is mostly adequate.

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 input schema covers 100% of the parameter (cluster) with a description listing valid letters. The tool description does not add additional semantic meaning beyond what the schema already provides, so the baseline score of 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?

The description clearly states the tool returns an audit checklist of a cluster, separated into real consensuses (★) and unique voices (◇). This specific verb and resource, combined with the unique output format, effectively distinguishes it from sibling tools like get_benchmark or listar_huecos.

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 explicitly states the tool is for auditing a launch/closure in progress ("Usalo para auditar un lanzamiento/cierre en curso"). While it does not exclude alternatives, this provides clear context for when to use it, which is adequate given the explicit use case.

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