Skip to main content
Glama

travel-budget-calculator

Read-onlyIdempotent

Estimate the total cost of a trip from flights, lodging, food, activities, ground transport, and an optional emergency buffer. Picks sane per-destination defaults (US domestic, Europe, Southeast Asia, Latin America, Africa) from a mid-2025 Numbeo-style reference table when a cost isn't provided. Returns total, per-person, daily average, and a category breakdown.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysYesTrip duration in nights/days. Must be a positive integer ≤ 365. Use the number of nights you'll be away.
travelersYesNumber of travelers (adults equivalent). 1 for a solo trip, 2 for a couple, etc. Must be ≥ 1.
destinationYesTrip region — drives the reference daily-cost defaults. 'us-domestic', 'europe', 'southeast-asia', 'latin-america', 'africa', or 'custom' if you'll provide every cost yourself.
flight_costYesTotal cost of flights (or train/bus) for ALL travelers combined, in dollars. Enter 0 if you're driving or already have miles booked.
food_per_dayNoPer-person food and drink cost per day, in dollars. If omitted, the destination's reference default is used.
lodging_per_nightNoCost per night for lodging — the whole group (one room or shared Airbnb), not per person. If omitted, the destination's reference default is used.
transport_per_dayNoGround-transport cost per day for the whole group (cabs, rental car, transit passes), in dollars. If omitted, the destination's reference default is used.
activities_per_dayNoPer-person activities cost per day (museums, tours, tickets), in dollars. If omitted, the destination's reference default is used.
emergency_buffer_percentNoOptional safety margin applied to the subtotal, 0–50%. 10–15% is a common cushion for unexpected costs. Defaults to 0.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysYesTrip length echoed from the input.
totalYesGrand total trip cost, rounded to cents.
subtotalYesSum of the five line items before the emergency buffer is added.
breakdownYes
travelersYesTraveler count echoed from the input.
per_personYestotal / travelers, rounded to cents.
destinationYesDestination echoed from the input.
daily_averageYestotal / days, rounded to cents.
daily_costs_usedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context: automatic fallback to per-destination reference defaults (mid-2025 Numbeo-style) when costs are omitted, and the return shape (total, per-person, daily average, category breakdown). This exceeds what annotations alone provide.

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 three sentences, front-loaded with the core purpose, and each sentence earns its place: function, defaults behavior, and output summary. There is no fluff or redundancy. Ideal conciseness for the tool's complexity.

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?

Given the rich schema (100% param descriptions), annotations, and presence of an output schema, the description need not explain every detail. It covers non-obvious behavior (defaulting, output breakdown) and is complete enough for an agent to invoke the tool correctly. No significant gaps.

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?

The input schema provides 100% description coverage for all 9 parameters, including details like 'If omitted, the destination's reference default is used.' The description restates the category grouping but does not add additional parameter-level meaning beyond the schema. Per the baseline for high schema coverage, this is a 3.

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 tool's purpose: 'Estimate the total cost of a trip' with explicit categories (flights, lodging, food, activities, ground transport, emergency buffer). The destination scope (US domestic, Europe, etc.) further clarifies its resource. It distinguishes itself from sibling cost calculators like road-trip-cost-calculator by focusing on multi-category trip estimation rather than just driving costs.

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 trip budgets, including optional per-destination defaults. It does not explicitly contrast with alternatives or state when not to use it, but the context is sufficient for an agent to select it appropriately. No misleading or exclusionary guidance is present.

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