derive_kill_criteria

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

With no annotations provided, the description carries the behavioral burden. It discloses the output shape (one row per rule with rule, threshold, status, evidence?), enumerates status values, and explains the design intent of falsifiable rules. It does not mention edge cases or side effects, but the derive verb and transformation nature make the tool's read-only, computational behavior clear.

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?

Two sentences, front-loaded with the core action and input sources, then the output contract. The final clause about replacing prose kill criteria earns its place by giving the rationale for the tool's existence without adding fluff.

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 derivation tool with no output schema and no annotations, the description provides the essential output contract and input provenance. It is slightly incomplete in that it does not specify behavior when no inputs are provided or whether all three inputs are required, but the overall guidance is sufficient for an agent to invoke it correctly in the intended flow.

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 description maps unitEcon and dealbreakers to the outputs of named sibling tools and adds meaning to icpDriftCount, which has no schema description. With 67% schema coverage, the description compensates for the undocumented parameter and clarifies the relationship between all three inputs.

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 states a specific verb ('derive'), a concrete result ('falsifiable, data-driven list of kill criteria'), and the exact upstream inputs. It clearly differentiates from the sibling compute_* tools by describing an output that is a set of rules with statuses, not a single computed metric.

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?

It explicitly identifies when the tool should be used: after validate_unit_economics and compute_dealbreakers_v2, and as a replacement for prose kill criteria. It does not enumerate exclusions or alternative tools, but the upstream-signal framing gives sufficient usage context.

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