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

Even with annotations present, the description adds meaningful behavioral context: the current process terminates, Aura holds the state and watches the condition, the state is returned byte-identical on resume, and a callback POST is optional. It does not disclose expiration behavior or the immediate return contract, but it goes well beyond the minimal annotations.

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 compact and well-structured: core behavior first, then usage guidance, then cost. Every sentence earns its place, and the critical safety/persistence semantics are front-loaded. No filler or redundant schema repetition.

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?

The nested `on` schema is complex, and while the description gives a solid high-level mental model, it omits important operational details for an agent invoking the tool: how the park call's response enables the later `resume`, and what happens when `expires_in_hours` passes. There is no output schema to fill this gap, so the description is adequate but not fully 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?

Schema description coverage is 80%, so the schema already carries most parameter meaning. The description adds a little context around state preservation and the callback, but it mostly restates what the schema says and does not clarify `expires_in_hours`, which lacks a schema description. This matches the high-coverage baseline of 3.

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-plus-resource ('park state and exit') and precisely distinguishes the tool from the sibling `resume` by framing park as the handoff that is later resumed. It also clarifies the asynchronous wake-condition model rather than just restating the title.

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?

The 'When to use' paragraph gives explicit context: use when the wait outlasts the process, such as hours/days or an approval landing tomorrow, and frames it as cheaper/safer than staying alive. It does not name explicit alternatives or exclusions like 'use await for short waits,' so it falls just short of a 5.

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