check_environment

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

No annotations exist, so the description carries the burden, and it does disclose a lot: which checks run, that an engine self-test actually executes record/replay/reverse, that a traced QuantLib call must attribute leaves to C++, and that findings include the pip command that fixes each issue. It does not state whether the tool itself installs anything or how long the self-tests take, so an agent can't fully predict cost or side effects.

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 action guidance ('Call it first; call it again after installing anything') is front-loaded before the long enumeration of checks, and every listed check is specific rather than filler. The middle sentence is dense and comma-heavy, which costs a little readability.

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 annotations and no output schema, the description must convey what comes back, and it does: package versions, platform, licence state, two self-test outcomes, and actionable findings. What's missing is the shape/format of those findings and whether remediation is advisory or applied, but for a zero-parameter diagnostic the coverage is close to 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?

The schema has zero parameters, which is the baseline-4 case; the description correctly implies no inputs are required and focuses entirely on what the call reports. Nothing about parameters needs explaining.

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: it measures what the interpreter can do with AADC and the Tracer, enumerating concrete checks (package versions, platform, licence, engine self-test, tracing self-test, findings with fix commands). The expected self-test result (dz/dx = 6 at x = 3) grounds the purpose in observable output rather than restating the tool name.

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?

'Call it first; call it again after installing anything' gives explicit ordering guidance and a re-invocation trigger, which routes the agent correctly against the trace/replay siblings. It doesn't name an alternative tool or state a when-not condition, which keeps it from a 5.

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