mutate

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

With no annotations, the description carries the full burden and does well: it discloses that it operates on COPIES (non-destructive to the original), that each survivor indicates untested behavior, that some mutants are equivalent and require judgment, and that it is currently Python-only. It omits resource/timing expectations and test-framework prerequisites, but the core behavior is well conveyed.

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 key mechanism is front-loaded in the first sentence, and parameters are cleanly structured in an Args block. The survivor/equivalence note is useful but slightly expands the prose; nothing is egregiously wasteful.

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 complex, multi-step operation this covers the mechanism, all parameters, and the language limitation, and an output schema exists so return values need not be documented. Absent any annotations, it could say more about runtime expectations or required test tooling, but it is largely 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?

Schema description coverage is 0%, so the description must compensate and it documents all four parameters. The path/file entries add real meaning (absolute project path vs. optional project-relative single file), while max_mutants and timeout are closer to restatements though timeout adds 'en total' (overall budget).

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 names a specific technique (mutation testing: injecting small bugs into COPIES of the code and checking whether tests catch them) with a concrete resource (the project/code under test). It is clearly distinguishable from siblings like 'test' (runs tests) or 'fix' (repairs code). An agent knows exactly what this does.

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 opening question '¿Los tests son buenos?' establishes the use case — assessing test quality — and 'Hoy solo para Python' is an explicit scope limitation. However, it never routes the agent among siblings (e.g., when to reach for mutate vs test) nor states when not to use it.

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