Smoover Moving Cost Calculator

Get a live moving price estimate

get_moving_estimate

Read-onlyIdempotent

Calculate an indicative price range (EUR incl. VAT) for a household move between two places in the EU, Switzerland or the UK. Uses truck road routing with real tolls, the vehicle needed for the volume and the loading/unloading crew. Prices three service levels: truck_driver (truck and driver only, the customer loads and unloads), standard (crew loads, wraps furniture and unloads; default) and premium (standard plus packing boxes and dismantling/reassembling furniture). Returns low/high price for the chosen level, the ranges of all three levels, distance, vehicles, crew and a link where the user can request a binding fixed-price quote. Takes a few seconds. Does not create a booking.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "origin": "<origin>",
      "origin_country": "<origin_country>",
      "destination": "<destination>",
      "destination_country": "<destination_country>",
      "volume_m3": "<volume_m3>"
    },
    "name": "get_moving_estimate"
  }
}

Input Schema

Name	Required	Description	Default
`origin`	Yes	Start city, postcode or street address, e.g. "Munich" or "10115 Berlin"
`service`	No	Service level: truck_driver = truck and driver only (customer loads), standard = with moving crew, premium = crew also packs boxes and dismantles/reassembles furniture	standard
`language`	No	Language of the matched addresses and the quote form	en
`volume_m3`	Yes	Volume in cubic metres. Typical: room 5, studio 10, 1-bed flat 15, 2–3 bed flat 25, house 50. Ask the user if unknown.
`destination`	Yes	Destination city, postcode or street address
`origin_country`	Yes	ISO 3166-1 alpha-2 country code of the start, e.g. DE
`destination_country`	Yes	ISO 3166-1 alpha-2 country code of the destination, e.g. ES

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

addedInput schema / properties / service

Added value: +{
+  "default": "standard",
+  "description": "Service level: truck_driver = truck and driver only (customer loads), standard = with moving crew, premium = crew also packs boxes and dismantles/reassembles furniture",
+  "enum": [
+    "truck_driver",
+    "standard",
+    "premium"
+  ],
+  "type": "string"
+}

First observedNov 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), it discloses pricing methodology (truck routing with real tolls, vehicle sized to volume, crew), latency ("a few seconds"), and the indicative-vs-binding distinction. It also compensates for the missing output schema by enumerating what comes back: low/high prices, all three ranges, distance, vehicles, crew and a quote link.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and price basis, then service tiers, then return contents and the booking disclaimer. Dense but a single overlong sentence with stacked parentheticals makes it slightly harder to scan than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, no-output-schema tool, the description covers inputs, pricing model, service tiers, latency and what is returned. An agent has everything needed to call it and to explain results to a user without further discovery.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents origin/destination, volume, language and the service enum in comparable detail. The description restates the three service tiers rather than adding new semantics, so it lands at the baseline for a fully documented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Calculate an indicative price range (EUR incl. VAT) for a household move between two places" gives a specific verb, resource, currency basis and geographic scope. The service-level breakdown and the closing "Does not create a booking" distinguish it from a booking or volume-sizing tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is clear (EU/CH/UK household moves, default standard level), and "Does not create a booking" heads off the most likely misuse. It never names the sibling get_move_sizes or says when to prefer it, so routing between the two is left to inference.

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

All Smoover Moving Cost Calculator tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?