Haulest

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds substantive context beyond that: which live data is pulled (operating authority, insurance on file, safety rating when available), that Canada returns guidance rather than a lookup, and that the output includes the official record URL for confirmation. It stops short of noting behavior for unmatched records or rate limits.

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 in the first clause, followed by jurisdiction specifics and a short usage sentence. The middle sentence is dense but each element (US sources, UK source, Canada fallback, return value) carries needed information; only minor tightening is possible.

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?

With no output schema, the description carries the return-value burden and does so by naming the official record URL and the fields surfaced. Coverage of all three markets plus the pre-deposit usage motive makes it complete for a two-parameter, read-only lookup tool.

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 100%, so the two parameters are already fully documented, including the us/uk/ca enum meaning and the acceptable query identifiers. The description largely restates this scope by jurisdiction and adds little syntactic or edge-case detail, so the baseline of 3 is appropriate.

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?

Names a specific verb and resource ('looks a moving company up in the official register') and scopes it by jurisdiction (FMCSA/USDOT/MC for the US, Companies House for the UK, guidance for Canada). It is clearly distinguishable from siblings like find_movers and get_mover_profile, which deal with discovery and profiles rather than official licence verification.

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 trigger: 'Use it before anyone pays a deposit or when a quote names a USDOT.' That is real when-to-use guidance tied to a decision point. It does not, however, contrast itself against nearby siblings such as get_mover_profile or find_movers, so the routing is clear but not exhaustive.

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

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

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context the annotations don't: the numbers come from published industry tables and public quotes rather than a mover's bid, and distance is resolved from stored route data "where it can" (hinting at a fallback). It stops short of describing behavior when no route is found or what currency/format guarantees apply.

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, each earning its place: what is returned, how distance may be supplied, and the nature/caveat of the data plus the usage trigger. The return shape and caveat are front-loaded before the usage note.

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?

No output schema exists, but the description explicitly characterizes the return value (low and high with currency). Combined with the 100% schema coverage and the annotation safety profile, an agent has everything needed to select and call this tool correctly.

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 100%, so the baseline is 3, but the description adds the crucial relationship the schema does not express: distanceBand, miles, or from/to are alternative ways to supply distance, and the tool resolves distance itself when given places. That mutual-exclusivity/priority information is genuine added value beyond the per-field descriptions.

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 ("Returns Haulest's research planning range... for a household move") plus scope (US, Canada, UK) and the inputs it derives the estimate from. It also implicitly separates itself from quote-obtaining siblings by calling the output a research range rather than a bid.

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?

"Use it when someone asks what a move might cost" gives a clear triggering context, and "not a bid from a mover" steers the agent away from treating it as a quote. However, it never names the alternative sibling (e.g. request_moving_quotes) that covers the actual-quote case, so the routing is implied rather than explicit.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds real value beyond that: results are restricted to companies with dated, attributed reviews, ratings are means of on-record reviews, Haulest does not rank by payment, and coverage is limited to US/CA/UK. Minor gaps remain (pagination behavior, handling of places with no matching companies).

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?

Two sentences, both earning their place, with scope and return fields front-loaded before the usage instruction. The first sentence is dense with a long field list, which is justified by the absence of an output schema, though it reads heavily.

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?

With no output schema, the description compensates by enumerating the returned fields (average rating, review count, newest review date, USDOT, profile URL). Parameters are fully documented by the schema, so nothing an agent needs to call this correctly is missing.

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 100%, so all five parameters (place, market, sort, limit, minReviews) are already documented in the schema, including enums and examples. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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 (lists moving companies) plus precise scope: places where Haulest holds dated, attributed reviews, limited to US, Canada, and UK. It also enumerates the returned fields and explicitly names the follow-up tool, so an agent can distinguish it from get_mover_profile without opening either schema.

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?

"Use it when someone wants movers in a place; follow with the profile tool for one company" gives a clear trigger condition and routes a common adjacent case to the right sibling. It stops short of explicit exclusions (e.g., licence checks belong to check_mover_licence), so it is strong but not fully exhaustive.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open world), so the bar is lower, and the description still adds real context: FMCSA authority/insurance is 'live' and only 'when available', the phone comes from a public record, and only the three newest dated reviews are returned. These are behavioral/data-quality caveats the annotations cannot express. It stops short of stating caching, rate limits, or failure behavior for an unknown slug.

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?

Front-loaded with the core purpose followed immediately by the usage trigger, and every listed field carries information. The middle enumeration is long and comma-spliced, which makes it denser than it needs to be, but nothing is padded or 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?

There is no output schema, so the description correctly carries the burden of describing the return shape, and it does so item by item including conditional fields ('when available'). Combined with the annotations and complete schema coverage for the single parameter, an agent has everything needed to call this correctly.

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 100% and the single slug parameter is already documented in the schema, including its provenance from find_movers and its derivation from a haulest.com/movers/... URL. The description mentions the profile URL in the return payload but adds no syntax or format guidance for the slug itself, so this is the baseline 3.

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 ('One moving company in detail from its Haulest profile') and then enumerates the exact payload: ratings, reviews, USDOT/MC licence IDs, FMCSA authority and insurance, phone, prices paid, strengths, and profile URL. This is clearly differentiated from the sibling find_movers, which discovers rather than retrieves one company.

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?

Explicitly routes the agent: 'Use it after find_movers or when someone names a company that has a Haulest page.' Both the triggering condition and the upstream sibling are named, so the agent knows exactly when this tool is the right pick versus discovery or licence-check tools. No exclusions are stated, but the positive routing is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so safety is covered. The description adds that results are grouped by section and what each checklist covers, which is useful but not deep behavioral disclosure (no pagination, caching, or auth notes).

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?

Two sentences, with the return behavior front-loaded and the usage cue trailing. The variant enumeration is long but each item earns its place by clarifying distinct outputs; nothing is wasted.

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 single-enum, read-only lookup with no output schema, the description covers what is returned and when to use it. Return-value structure is described at a high level (grouped by section), which is sufficient 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?

Schema coverage is 100% with the lone param being an enum whose description is just 'Which checklist.' The description compensates by spelling out what each of the seven options actually contains (8-week countdown, moving day, first-night box, US/CA/UK change of address, 12-week international), which meaningfully aids selection beyond the raw enum values.

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 (Returns) and resource (one of Haulest's checklists), and enumerates the seven checklist variants so the agent knows exactly what content is available. It is clearly distinguishable from siblings like search_moving_guides or estimate_moving_cost.

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 one triggering condition ('Use it when someone wants a to-do list for a move') but names no alternatives or when-not conditions. Adequate context, but the agent gets no guidance on how this differs from search_moving_guides for the same intent.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: geographic coverage (main US, Canadian, and UK lanes) and the graceful not-covered fallback. It does not describe response ordering or granularity beyond the field list, keeping it out of the 5 band.

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?

Two sentences, zero filler. The return payload is front-loaded so an agent knows immediately what it gets, and the usage/fallback sentence follows. Every clause earns its place.

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?

With no output schema, the description correctly carries the burden of telling the agent what comes back, and it does so by enumerating the returned facts. Coverage limits and the not-covered behavior round out what an agent needs before calling.

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 100% and both parameters carry their own descriptions, including the 'Austin' / 'Austin, TX' format example. The description's 'names both ends of a move' restates what the schema already defines, adding little syntax or format guidance beyond it. Baseline 3 applies when the schema does the heavy lifting.

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 names a specific resource (a city-to-city moving lane) and enumerates exactly what is returned: driving miles/hours, research cost range by home size, Census household flow between states, and the page URL. That specificity lets an agent distinguish this lookup from siblings like estimate_moving_cost or find_movers without opening the schema.

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 clear trigger ('Use it when someone names both ends of a move') and an explicit negative case ('returns a clear not-covered message otherwise'), which is a real when-not condition. It stops short of naming alternatives it should be preferred over (e.g. estimate_moving_cost), so it falls just below the top band.

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

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

Goes well beyond the annotations: discloses that Haulest is a lead desk rather than a carrier, that calls may arrive within minutes in the US/UK, that each call creates one request, and that same phone/email within a day is de-duplicated. It also states the return shape ('a request reference and what happens next'), which matters because there is no output schema.

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?

Six tight sentences, front-loaded with the action and the lead-desk mechanism, then the consent gate, then dedup behavior, then the return. Every sentence carries a distinct fact an agent needs; nothing is filler.

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 15-parameter mutation with no output schema, the description covers what the tool does, the hard consent prerequisite, third-party contact timing, idempotency-like dedup behavior, and the shape of the response. Nothing material is missing.

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 100%, so all 15 parameters are already documented in the schema. The description restates the consent requirement and the name/phone/email gate but adds no syntax or format detail beyond what the schema provides, so the baseline of 3 applies.

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 ('Submits a quote request to Haulest') and immediately defines the mechanism: licensed movers call/email the person with written estimates. This is clearly distinguishable from siblings like find_movers or estimate_moving_cost, which don't create a lead-desk request.

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 precondition gate ('Call this only after the person has given their name, phone, and email for this purpose and has explicitly agreed to be contacted') plus a confirmation step before calling. No sibling alternative is named for cases where consent isn't given, so it stops short of the full when/when-not/alternatives pattern.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds non-annotation value by disclosing the return payload shape (title, one-paragraph answer, URL), which tells the agent the results are prose answers rather than raw documents.

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, zero filler: capability and coverage first, return shape second, usage criterion last. Nothing is repeated from the title or schema.

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?

With no output schema, the description compensates by describing the return payload, and the closed-world annotation is consistent with the stated internal Haulest corpus. Nothing an agent needs to decide whether and how to call this tool is missing.

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 100%, so both query and limit are already documented in the schema, including examples for query. The description adds no syntax, format, or behavioral guidance about parameters, so the baseline 3 applies.

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 (searches) and an unambiguous resource (Haulest's written guides, calculators, checklists), then enumerates the topic domains it covers. An agent can immediately separate this content-search tool from siblings like check_mover_licence or estimate_moving_cost.

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?

"Use it for how-to and what-does-this-mean questions about moving" gives an explicit selection criterion, and the enumerated domains imply what is out of scope. It does not name a competing sibling or state exclusions, so it stops short of a 5.

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