Run

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

With no annotations, the description fully carries the burden. It discloses critical edge cases: false success on missing calc layer, error reported via isError rather than text, and the dependency on project endtime. This level of transparency prevents an agent from misinterpreting results.

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 description is dense and well-structured. It front-loads the core action, then methodically covers pitfalls and error semantics. Every sentence adds value, and the length is appropriate for the complexity—no filler or redundancy.

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?

Given the tool's complexity and the existence of an output schema, the description covers all essential behavioral aspects: success criteria, failure signaling, time constraints, and a pointer to a related tool. An agent has everything needed to call it correctly without guessing.

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 100%, so the baseline is 3. The description adds meaningful context for to_time by explaining its relationship to project endtime and the practical implication of setting it too high. It does not add detail to wait_timeout or stall_seconds beyond schema, but the added to_time insight justifies a 4.

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 clearly states the action (run project calculation) with an optional time limit, and distinguishes its behavior from a naive run by emphasizing the check on actual model time. This differentiates it from siblings like step and stop, making the tool's purpose specific and unambiguous.

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 explains when the tool returns success without advancing time (no calc layer or disconnected inputs), and advises to check actual time rather than return code. It also explicitly mentions that to_time beyond project endtime is unreachable and directs to set_calc_time as an alternative. However, it does not explicitly contrast with step for incremental execution, leaving some ambiguity.

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