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

Annotations declare this is a non-read-only, non-idempotent, non-destructive write, and the description adds valuable context: it produces charts and a written report, and runtime is quoted by path_resolver (implying a long-running call). It doesn't say whether the run is asynchronous, how results are retrieved afterward, or what happens to prior outputs, so meaningful behavioral gaps remain.

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?

Three short, front-loaded fragments with no filler; the deliverable and the time expectation come before caveats. The terse 'Time: as path_resolver quotes' is a little clipped but earns its place by warning about an upfront estimate.

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 an 8-parameter, non-idempotent execution tool with no output schema, the description covers the purpose and deliverables but leaves the operational picture thin: no indication of async/polling, cost accounting, or how the returned report and charts are surfaced. Adequate to select the tool, not fully adequate to invoke it confidently.

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 coverage is 63%, and the description adds no parameter-level guidance at all. Undocumented in both schema and description are tool_names (where the tool names come from), module_parameters, and estimate_id, and nothing explains how column_mapping interacts with the resolution_id flow.

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 ('Run one or more tested library tools on this dataset') plus the deliverables (charts and a written report), and rules out custom builds. It doesn't name path_bespoke as the alternative, but 'No custom build' signals the boundary clearly enough to distinguish it from the bespoke-path sibling.

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?

Gives a clear when-to-use context (tested library tools, no custom build) and points at path_resolver as the source of the time quote, which implies the resolution_id prerequisite. It stops short of naming explicit alternatives or stating when re-running / estimate flows should be used instead.

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