legal_litigation_hold_loop

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered structurally. The description adds modest context about scope — that calls run 'under your JWT, tenant, and company scope' — which is useful for understanding auth boundaries. However, it does not disclose what destructive effects the loop may have or whether it is long-running/asynchronous, and it does not contradict the 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 — roughly six short lines including the Args listing — with the core directive front-loaded. The routing sentence is of marginal value but short. Every line earns reasonable keep, and there is no bloat or repetition of schema defaults.

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 a destructive, non-idempotent action with 0% schema coverage and several closely-related litigation-hold siblings, the description is under-specified. It fails to explain what the litigation_hold_loop does, when to prefer it over issue/refresh/release variants, what its destructive impact is, or what inputs it expects. An output schema exists, which covers return values, but that does not compensate for missing invocation and selection semantics.

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 0%, so the description carries the burden for explaining parameters. It provides minimal but real semantic value: 'message' is a free-text objective and 'inputs' is an optional JSON string of structured inputs. However, it does not specify what structured inputs this particular action accepts, what fields are valid, or how the message and inputs interact, leaving the agent to guess at invocation details.

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 opens with 'Run the legal domain agent action `litigation_hold_loop`', which restates the tool name with a generic verb rather than explaining what the action actually does. No mention of litigation holds, preservation duties, custodians, or what a 'loop' accomplishes, making it nearly a tautology. Sibling tools like legal_litigation_hold_issue, legal_litigation_hold_refresh, and legal_litigation_hold_release suggest specific hold operations, but nothing distinguishes what this loop variant performs.

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?

No guidance is provided on when to use this tool versus alternatives such as legal_litigation_hold_issue, legal_litigation_hold_refresh, legal_litigation_hold_release, or dispatch_domain_agent. The routing sentence ('Routes through the platform's domain-agent dispatcher') describes implementation mechanics, not a selection criterion. An agent cannot determine under what circumstances this loop should be invoked.

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