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

The description adds real behavioral context beyond the annotations: divergence is framed as a finding rather than an error, mean-field gaps and threat-blindness are named, and the gated-net exception is disclosed. It does not, however, reconcile or explain the heavy side of the annotation profile (destructiveHint=true, openWorldHint=true, non-idempotent) for what reads as an analytical report tool, and says nothing about the compute cost of the SSA realizations it runs.

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?

Purpose is front-loaded in the first clause, and every subsequent sentence carries distinct information (the enumerated readings, the divergence policy, the gated-net exclusion, the docs pointer). The dense em-dash parentheticals make it heavier than necessary but not 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?

With no output schema, the description partially compensates by naming what is reported (agreement or divergence plus reason), which is valuable. It still leaves the agent without an idea of response shape, runtime, or why a cross-check tool carries destructive/open-world hints, leaving gaps for a tool with three parameters and non-read-only annotations.

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 all three parameters (id, hours, realizations) carry descriptions with defaults and maxima, so the schema does the heavy lifting. The description adds no parameter-level meaning, such as how hours interacts with the comparison or what realizations imply for result stability, making the baseline 3 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 and resource: runs every applicable 'reading' of a model against the others and reports agreement or divergence, enumerating the concrete comparisons (discrete SSA vs mean-field, conservation laws vs simulated means, incidence ranking vs rollouts vs search). This is a distinct capability an agent can separate from sim_verify or sim_conformance, though it never explicitly names a sibling to route against.

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?

Usage is implied through the applicability rules: gated nets have no ODE reading, and readers are pointed at docs/engine-selection.md for the four-rule decision. However, there is no explicit 'use this instead of X when Y' statement, nor a clear precondition beyond an id.

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