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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description then adds genuine business rules not in the annotations: 90 free days are shared across the same batch rather than reset, and Yanwen rates already bundle standard pick-pack. It stops short of stating auth requirements or how currency is derived.

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 core purpose is front-loaded and every sentence carries a rule or a mapping, with no filler. The middle section is telegraphic fragment lists that require a careful read, 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?

For an 8-parameter, single-required, no-output-schema estimator, the description covers the service-to-parameter mapping, duration semantics, and pricing caveats. The only real gap is that return shape is only implied by "public USD starting costs" rather than said explicitly, which is minor given there is no output schema.

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?

With schema coverage at 63%, the description compensates by mapping each service to its relevant inputs (sampleChecks for inspection, units for prep, orders for standalone pick-pack, cubicMeters + duration + alreadyStoredDays for storage), which the schema does not express. It also reiterates the 30-day month convention and the conditional alreadyStoredDays case, adding meaning beyond field names.

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: "Estimate public USD starting costs" at a base level, and clarifies the hard boundary ("does not quote, bill, purchase or ship"), which separates it from ordering/billing flows. It does not name or contrast with the siblings list_prepport_services or plan_prepport_first_job, so an agent still has to infer which estimator to pick.

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 concrete invocation routing by service: inspection needs sampleChecks, prep needs units, standalone pick-pack needs orders, storage needs cubicMeters plus a duration. It also supplies an exclusion ("Sourcing is quote-only") and warns against double-counting the pick-pack fee for Yanwen parcels, though it never explicitly compares scope against the sibling tools.

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