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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds two real behavioral notes: dispatch review is advisory, and calculations return a replayable receipt. However, the trailing boilerplate about REST fields and 'follow its required fields' adds confusion rather than behavioral context, and it says nothing about how ambiguity in the supplied check statuses affects 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?

Purpose and mode routing are front-loaded and efficient, but the tail contains low-value boilerplate ('Follow its required fields and exact choices') and an opaque negative rule about a REST calculator field that an MCP agent has no way to interpret. 'Supply units or modelVersion only when listed in inputSchema' is self-referential filler, since units is an empty object.

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?

An output schema exists, so return values need no explanation, and optional lookup fields carry inline schema descriptions. Still, for a tool with four distinct modes and heavy nesting, the description gives no guidance on combining modes, on which optional dispatch-review checks materially change the advisory outcome, or on the units field's empty-object restriction.

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?

Top-level schema description coverage is 0%, and the description must carry meaning for a deeply nested four-way oneOf. It does explain what each mode's payload is for (funding events, calibrate-hours forecast/calibration/validation, dispatch-review bid/ranges/checks) and that fields belong under inputs. But it never explains required numeric fields like marginFloor, contingencyCash, schedule.minimumPercent, or the confirmed/unconfirmed/conflict check enums, leaving much semantic weight to the schema.

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 first sentence names specific verbs and outputs: calculate bid margin, break-even thresholds, and 27 combinations across fuel price, standby hours, and delay days. It also enumerates the alternative modes (funding, calibrate-hours, dispatch-review). It never distinguishes this tool from break-even-oriented siblings such as buscalc_break_even_sales or buscalc_markup_vs_margin, so an agent cannot fully rule those out from the description alone.

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?

Each mode is tied to a concrete situation: funding for dated cash requirements, calibrate-hours for a productive-hours range from matched prior forecasts and actual hours, dispatch-review for evaluating a bid with supplied readiness/source statuses. It also routes source-snapshot needs to buscalc_emergency_source_lookup. There is no explicit when-not guidance or exclusion against the break-even siblings.

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