Nationwide long-distance moving quotes ($0.01 via x402) and free date holds. Local moves DC/MD/VA.
Scored across 3 tools
The three tools map to clearly different intents: business facts, price estimation, and date-hold booking. The only blur is that get_quote's description embeds licensing and service-area details that also belong to company_info, which could make an agent unsure which tool to consult for company facts.
get_quote and request_booking follow a consistent verb_noun pattern, while company_info is a bare noun phrase. The deviation is minor and the names remain readable and predictable.
Three tools is on the thin side but each maps to a real step in a moving-company lead funnel (learn, price, book). Nothing extraneous is present, though the surface is minimal.
The core flow of info → quote → booking request is covered, but there is no way to check booking/hold status, cancel or modify a request, or schedule the free survey that request_booking explicitly references. These gaps would leave an agent at a dead end after submitting a request.
Facts about Next Generation Movers: licensing, service area, contact.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Facts about' implies a safe read-only lookup, and '(free)' in the title hints at no cost, but the description never states there are no side effects, no auth, or no rate limits. For a zero-parameter read tool the risk is low, so a 3 is fair.
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?
A single front-loaded sentence that lists the three content areas without filler. Slightly sparse but every word 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?
For a zero-param tool with no output schema, the description effectively outlines what is returned (licensing, service area, contact), which is the key missing piece an agent needs. Nothing critical is absent.
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?
The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 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?
The description names a specific resource (facts about Next Generation Movers) and enumerates the content returned: licensing, service area, contact. It's immediately distinguishable from get_quote and request_booking as the informational/static lookup, though it doesn't explicitly say so.
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?
Usage is only implied: an agent should infer it's for answering factual questions about the company (licensing, service area, contact) before booking or quoting. No explicit when-to-use or when-not-to-use guidance against get_quote or request_booking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nationwide interstate and long-distance household moves between any two US states, plus local moves in the DC/Maryland/Virginia area. Licensed carrier USDOT 3764697, MC 1341637. Indicative price per tariff (not a legal estimate) between any two US ZIP codes. Long distance nationwide, per cubic foot by distance and size; local hourly in DC, MD, VA only. Costs $0.01 (x402, USDC on Base). Invalid input is rejected before payment.
| Name | Required | Description | Default |
|---|---|---|---|
| safes | No | Number of safes, $500 each | |
| to_zip | Yes | Destination 5-digit US ZIP, any US state. Over about 50 road miles is priced as long distance per cubic foot; shorter moves are priced hourly only within DC/MD/VA | |
| packing | No | Full packing at $1.25 per cf (long distance) | |
| shuttle | No | Shuttle truck needed, $1.25 per cf, $700 minimum | |
| bedrooms | No | Alternative to home_size | |
| from_zip | Yes | Origin 5-digit US ZIP | |
| crew_size | No | Local only: 2 movers $229/hr, 3 movers $259/hr, 4 movers $299/hr | |
| est_hours | No | Local only: estimated labor hours (3-hour minimum) | |
| home_size | No | Home size; used to estimate cubic feet (long distance) or crew and hours (local) | |
| inventory | No | Optional item list; cubic_feet (or weight_lbs, converted at 6.5 lb/cf) per item | |
| move_date | Yes | Earliest pickup date, YYYY-MM-DD | |
| unpacking | No | Full unpacking at $1.25 per cf (long distance) | |
| cubic_feet | No | Total shipment cubic feet, if known (350 cf minimum applies) | |
| extra_stops | No | Extra pickup or delivery stops, $150 each | |
| stairs_flights | No | Flights of stairs, $75 per flight | |
| storage_months | No | Months of storage, $50 per 100 cf per month | |
| long_carry_feet | No | Long carry distance in feet, $100 per 75 ft | |
| specialty_items | No | Bulky items with a tariff handling charge | |
| guaranteed_delivery | No | Guaranteed delivery date, 42% of line haul (long distance) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description still discloses key behavioral facts: cost of $0.01 paid in USDC on Base via x402, pre-payment validation that rejects invalid input, tariff-based (non-binding) pricing, and carrier licensing numbers. It omits response shape, quote validity period, and any rate limits, but the payment and validation disclosures are substantive.
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?
Four dense sentences, front-loaded with scope before licensing, pricing model, and payment mechanics. Every sentence carries information; only the USDOT/MC numbers are arguably filing trivia for an agent.
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 19-parameter tool with no annotations and no output schema, the description explains the pricing model and payment flow but never says what the response contains (price breakdown, validity, next step to book). That leaves a real gap around return values that no structured field covers.
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 already 100%, so the baseline is 3; the description adds real meaning by explaining that from_zip/to_zip distance selects cubic-foot long-distance pricing versus hourly local pricing only in DC/MD/VA. That framing helps an agent decide which parameter families (crew_size/est_hours vs cubic_feet/home_size) apply.
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 precisely what is priced: indicative household-move quotes between any two US ZIPs, with long-distance per-cubic-foot pricing and local hourly pricing confined to DC/MD/VA. The verb 'quote/pricing' and resource are clear, though it never names its sibling request_booking as the downstream step, so the distinction is only implicit.
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?
Usage context is implied by the pricing model (give ZIPs and date to get a price; local DC/MD/VA inputs trigger hourly pricing), but there is no explicit when-to-use or when-not guidance versus company_info or request_booking. The payment/validation note ('invalid input is rejected before payment') is a useful operational cue but not a selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free date-hold request with Next Generation Movers. No payment; the owners set the deposit and send the signed estimate after a free survey.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| to_zip | No | ||
| from_zip | No | ||
| quote_id | No | ||
| move_date | Yes | YYYY-MM-DD | |
| contact_name | No | ||
| contact_email | No | ||
| contact_phone | No | ||
| flexible_dates | No | ||
| idempotency_key | No | Unique key per booking request (UUID recommended). Reusing it returns the same request |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description does carry useful behavioral context: no payment is taken, the deposit is set by the owners, and a signed estimate follows a free survey. It still omits the important mechanics for a booking mutation — whether a record is created immediately, whether it can be cancelled or expires, and that contact details may be needed to confirm the hold.
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 tight sentences with no filler, and the most decision-relevant fact (free, no payment) is front-loaded. It is perhaps over-compressed for a 10-parameter mutation, but no sentence 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 10-parameter booking mutation with no annotations and no output schema, the description covers only the commercial framing. An agent still cannot tell what it gets back, what happens after submission, or how to populate most of the inputs.
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 only 20% across 10 parameters, so the description is expected to compensate and adds nothing about any of them. Fields like flexible_dates, quote_id, from_zip/to_zip, and the contact_* group are left entirely undocumented, and method='reusing idempotency_key returns the same request' lives only in 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 description names the specific action (a free date-hold request) and the provider (Next Generation Movers), so an agent knows exactly what committing to this call means. It does not explicitly contrast itself with the siblings get_quote or company_info, which keeps it below a 5.
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?
There is no statement of when to use this instead of get_quote, nor any prerequisite such as 'call get_quote first and pass its quote_id'. The presence of a quote_id parameter hints at an ordering, but the description never says so.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
company_infoget_quoterequest_bookingCompare and book movers or labor-only help. 16+ years, 1M+ moves, free online quotes.
Help estimating move size, inventory and quotes for house or office movers.
Filmed moving surveys, itemized inventories, firm quotes and bookings for moving companies.
Find, compare, and book local movers and moving-labor helpers via MovingPlace's marketplace.
Add one secure layer between your agents and this server.
