Skip to main content
Glama

road-trip-cost-calculator

Read-onlyIdempotent

Estimate the total cost of a road trip from fuel, lodging, food, attractions, and tolls. Supports both imperial (miles + MPG + $/gallon) and metric (km + L/100km + per-liter) inputs. Returns total cost, fuel-only subtotal, per-person split, and cost per mile/km.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tollsNoOptional total toll cost for the trip (in the same currency). Defaults to 0. Pulled out as its own line so the fuel subtotal stays a pure miles-per-gallon math.
distanceYesRound-trip driving distance. Use the unit specified by `unit_system` — miles for 'imperial', kilometers for 'metric'. For a one-way drive, double the one-way distance.
travelersNoNumber of travelers. Defaults to 1 when omitted. Used to compute per-person cost and to scale the food subtotal (food_per_day × travelers × duration_days). Lodging, fuel, attractions, and tolls are billed once per trip.
fuel_priceYesFuel price in local currency units. Dollars per gallon for 'imperial' (US average ~$3.50/gal mid-2025), or per liter for 'metric' (EU average ~€1.65/L).
attractionsNoTotal budget for attractions, activities, and entry tickets across the whole trip (in the same currency). Defaults to 0. Already a per-group total — not multiplied by travelers.
unit_systemNoWhich unit set the distance and fuel-economy inputs are in. 'imperial' = miles + MPG + $/gallon (default); 'metric' = kilometers + L/100km + price per liter.
food_per_dayNoAverage food cost per traveler per day, in the same currency as `fuel_price`. Defaults to 0 when omitted. Multiplied by `duration_days` AND `travelers` for the subtotal.
fuel_economyYesFuel economy. Higher-is-better when `unit_system` is 'imperial' (MPG, miles per gallon — e.g. 28 for an average US sedan). Lower-is-better when `unit_system` is 'metric' (L/100km — e.g. 8.4 for an average European car).
duration_daysYesTrip duration in whole days, including the departure day and return day. A weekend trip (leave Sat, return Sun) is 2 days; a week-long trip is 7.
lodging_nightsNoOverride for the number of paid lodging nights. Useful when you booked a night before departure or the return is an overnight drive. When omitted, the engine uses max(duration_days − 1, 0).
lodging_per_nightNoAverage lodging cost per night, in the same currency as `fuel_price`. Defaults to 0 when omitted (sleeping at home or with hosts). The engine bills lodging for (duration_days − 1) nights by default; override with `lodging_nights` if you booked differently.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
fuel_usedYesTotal fuel consumed for the trip — gallons when `unit_system` is 'imperial', liters when 'metric'. Rounded to two decimals.
per_personYestotal_cost ÷ travelers, rounded to cents.
total_costYesTotal trip cost in the input currency, rounded to cents.
unit_systemYesUnit system echoed from the input.
cost_per_mileYestotal_cost ÷ distance — the all-in cost per unit of distance. Per mile for 'imperial', per kilometer for 'metric'. Rounded to cents.
food_subtotalYesFood cost: food_per_day × travelers × duration_days.
fuel_subtotalYesFuel-only subtotal — what gas costs you for the round trip.
lodging_nightsYesNumber of paid lodging nights actually billed.
tolls_subtotalYesTolls subtotal, echoed from the input.
lodging_subtotalYesLodging cost across all paid nights.
attractions_subtotalYesAttractions/activities subtotal, echoed from the input.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

The description adds substantial behavior beyond the readOnlyHint/idempotentHint annotations by disclosing the return values (total cost, fuel-only subtotal, per-person split, cost per mile/km) and noting the unit handling. This gives agents a clear understanding of what the tool computes and returns.

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

Conciseness5/5

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

The description is two sentences long, front-loaded with the core purpose and immediately followed by supported inputs and outputs. Every word earns its place with no fluff or redundancy.

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?

Despite the tool's complexity (11 parameters, output schema), the description covers the essential output categories and unit flexibility. Since an output schema exists, detailed return structure is already available, making this description complete for tool selection and invocation.

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 description coverage is 100%, with each of the 11 parameters already documented in detail. The prose description repeats a few parameter concepts (imperial/metric units) but does not add meaning beyond the schema. Baseline 3 is appropriate since the schema carries the semantic burden.

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?

The description clearly states the specific verb 'estimate' and the resource 'total cost of a road trip', listing the cost components (fuel, lodging, food, attractions, tolls). It also distinguishes itself from sibling calculators by emphasizing road-trip-specific features like unit systems and per-person splits.

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?

The description provides clear context: it is for estimating road trip costs with support for imperial/metric units. However, it does not explicitly mention when not to use it or compare to alternatives like travel-budget-calculator, so it falls short of the top score.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources