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

Annotations only declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false; the description adds genuinely new context by disclosing that the call consumes points, that remaining steps are charged, and that billing is metered by model usage. It does not explain failure modes if the balance is insufficient survived or whether the resume can be aborted mid-run.

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?

Two tight sentences plus a short parenthetical; the resume condition and the cost warning are both front-loaded. The closing parenthetical about website-style metering partially restates the points-charging sentence, so it is near-redundant rather than pure value.

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 a metered, non-idempotent mutation with a small schema and no output schema, the description covers the states it accepts, the cost implication, and the resume semantics. The main remaining gap is what the caller should expect on return (new step id, run object) and what happens if charging fails partway.

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 both parameters are documented structurally, and the description implies 'id' identifies the run to resume. However, it adds no meaning about the id's format/scope and is silent on idempotency_key, leaving the schema to carry that burden. Baseline 3 applies when the schema does the heavy lifting.

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 uses a specific verb ('Continue') on a specific resource ('a deep research run') and names the eligible states (paused/stopped/failed) plus the resume point ('from the step it reached'), which distinguishes it from start_deep_analysis. It stops short of naming a sibling explicitly, so the differentiation is inferred rather than declared.

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 gives clear when-to-use conditions: only for runs that are paused because points ran out, stopped, or failed. It also adds a prerequisite action ('Check the balance first'), but never states the inverse case (e.g., do not use on a running or completed run) or points to get_account/get_deep_analysis for checking balance.

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