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

Adds substantial behavior beyond the annotations: it declares that statutory rates and results are refused by name, that unmappable fields are refused, and that the server-side workspace does all computation rather than accepting numbers. It also confirms and explains the idempotentHint by stating that re-sending the same WCB number and hearing date never creates a second tab, and names the follow-up tool for reading 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?

Dense but front-loaded: eligibility, then action, then input rules, then call sequence. No filler sentences, though the middle sentences are long and pack several rules into one clause chain, which slightly reduces scanability.

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 mutation tool with no output schema and a free-form array of nested case objects, it covers eligibility, input contract, refusal behavior, idempotency and the read-back path. The residual gap is the per-tile input key structure, which is delegated to describe_case_schema and is reasonably handled by the instruction to call it first.

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 0%, so the description must carry the load, and it largely does — it enumerates the facts to send (claimant label, WCB number, hearing date, date of accident, the AWW found, each tile's inputs) and states "inputs only." It also matches the schema's maxItems of 25. It never explains the `format` value "cdw-cases" or the `version` field, which remain undocumented in both schema and description.

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 — puts up to 25 of the attorney's cases into their own Pro Workspace as finished tabs with named calculator tiles (SLU, LWEC, CCP, Section 32, Burns, apportionment) filled in. This clearly distinguishes it from the many calculate_* siblings: this one imports cases, they compute single figures.

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 an explicit audience gate ("Signed-in Pro or Firm attorneys only") and an explicit call sequence: "Call describe_case_schema first; afterwards get_import_status returns the figures the workspace computed." It also implicitly routes agents away from the calculate_* siblings by saying the workspace computes every rate, award, fee and net itself.

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