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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description goes further by disclosing the actual computation path (all-hours divisor, over-credit and fringe owed on DBRA hours, defined-contribution pension exception checks), which tells the agent what the tool will decide rather than just that it is a safe read.

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?

Three sentences, front-loaded with the usage condition, then the regulatory mechanics, then a compact example. The example earns its place by disambiguating the math, though the parenthetical plan list and the trailing example add density that could be trimmed slightly.

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 regulatory calculation with a nested plan object, the description supplies the formula, the exception logic, and a concrete example, and an output schema exists so return values need not be described. The nested plan booleans are the only real gap, left to the schema's enum and property names alone.

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 80%, so the baseline would be 3, but the worked example maps every top-level parameter to a concrete value and clarifies the key semantic relationship (dbraHours is a subset of totalHoursWorked used as the credit denominator). It stops short of explaining the nested plan flags (unfunded, exceptionGranted, vestsWithinFirst500Hours), which remain the agent's inference.

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 and outcome: computing the hourly fringe credit a plan may take on Davis-Bacon payrolls, with the regulatory basis (29 CFR 5.25(c)) and the exact operation (plan cost divided by all hours worked). It is clearly distinguishable from siblings like reconcile_fringe_6b or build_certified_payroll, which concern reconciliation and payroll construction rather than deriving a single hourly credit.

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 a concrete triggering condition: a contractor pays a fringe plan for a worker who also does private work and needs the DBRA hourly credit. That is clear when-to-use guidance, but it never names an alternative tool or an exclusion case, so the agent must infer routing from siblings on its own.

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