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

Annotations only declare it is non-read-only and non-destructive; the description adds substantial behavioral context beyond that. It discloses that reconcile mutates run state, that at most one run is open per workflow, that edgeId selects a branch (including bypassed optional stages), and crucially that absent edgeId a delivered step is re-sent in full while other calls return only instruction titles — a subtle, high-value detail.

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?

Front-loaded with the core action and free of filler, with each sentence contributing behavior. It is dense and somewhat compressed, requiring careful reading, but nothing is redundant.

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 output schema, the description carries the return-behavior burden and does so well, explaining that the current step is delivered and that later calls return only instruction titles. Combined with the branch and run-selection behavior, it is largely complete for a stateful resume tool, though a brief statement of what the delivered step contains would round it out.

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 baseline is 3, but the description genuinely enriches the parameters: it explains that runId or workflowId disambiguate when several runs are open, and that edgeId chooses a configured branch including bypassed optional stages. This adds meaning the terse schema descriptions do not carry.

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 gives specific verbs (reconcile, read, deliver) and a clear resource (an open workflow run and its current step), distinguishing it conceptually from start_workflow and report_workflow_step. However, it never names those siblings to make the boundary explicit, so sibling differentiation is left to inference.

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?

Usage is implied by 'resume... an open workflow run' and the note about naming the run when several are open. It explains parameter-level conditional behavior well, but provides no explicit when-to-use guidance relative to alternatives like start_workflow or report_workflow_step, so the agent must infer the selection context.

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