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 cover safety (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely new behavioral context: the range comes from 'published industry tables and public quotes, not a bid from a mover', and distance is resolved from stored route data where possible. That tells the agent how much to trust the number and how the tool fills gaps, though it doesn't mention latency or failure modes.

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 what is returned before the sourcing caveat and the when-to-use clause. Each sentence carries distinct information (output, trustworthiness/sourcing, invocation), with no 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 read-only estimator with no output schema, the description adequately covers the return shape (low and high with currency), the geographic scope, the sourcing, and the flexible distance inputs. Minor gaps remain around edge cases (e.g. unmatched origins or empty route data), but nothing essential to correct invocation 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains that the caller may pass a distance band, a mileage, or an origin/destination, and that the tool resolves distance from stored route data otherwise. This clarifies how the three distance-related parameters interact, which the schema alone does not.

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 a planning cost range (low/high plus currency) for a household move – and scopes it to three countries. It also implicitly separates itself from request_moving_quotes by noting the figure is 'not a bid from a mover', so an agent can distinguish it from the sibling quote tool without opening a 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 asks what a move might cost' gives a clear triggering context, and the 'not a bid from a mover' contrast steers agents away from treating it as a firm quote. It stops short of naming request_moving_quotes as the alternative for actual bids, 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 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?

Adds substantial behavior beyond the annotations: the lead desk may phone within minutes in the US/UK, each call creates one request, a repeat with the same phone or email within a day is recognised and not duplicated, and a request reference is returned. The dedupe window sits in mild tension with idempotentHint=false, but it is a stated business rule rather than a contradictory claim about the operation type, and the rest is high-value disclosure.

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 action and its actor, followed by the mechanics and preconditions in a logical order; no sentence is filler. It runs slightly long and could compress the Haulest-role sentence, but 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 15-parameter form submission with no output schema, the description covers purpose, consent gating, dedupe, and the shape of the response ('a request reference and what happens next'). What remains unsaid — optional-field handling and full return content — is either in the schema or minor for a submission 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% and all 15 parameters are documented in the schema itself, so the baseline is 3. The description only echoes the consent and contact-detail requirements already spelled out in the schema, adding no format, boundary, or trade-off information beyond it.

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 so licensed movers contact the person — and clarifies the company's role ('Haulest is not a carrier; it introduces the request to movers'). An agent can distinguish this from find_movers or check_mover_licence without opening any 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?

Gives a hard precondition ('Call this only after the person has given their name, phone, and email... and has explicitly agreed to be contacted; confirm the details back to them first'), which is unusually explicit usage context. It does not, however, name sibling alternatives (e.g. estimate_moving_cost for a price-only enquiry), so routing is inferred rather than stated.

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