Family trip cost estimates with a sourced, dated range for every line, from Endless Travel Plans.
Scored across 1 tool
With only one tool on the server, there is no possibility of overlap or misselection; its purpose (family trip budget estimation) is unmistakable and self-contained.
The single tool follows a clean snake_case verb_noun convention (estimate_family_trip_budget) that is descriptive and predictable, so consistency is trivially satisfied.
A single tool is thin for a server, offering no parameterized alternatives such as comparing destinations or refining a saved estimate, but it does fully encapsulate the stated calculator purpose.
The tool covers the full lifecycle of a budget estimate (cost categories, low-to-high range, sourcing, confidence, unsupported-region handling, and a live-price handoff URL). Minor gaps only: no ability to compare multiple trips or persist/update a prior estimate.
Estimate what a family trip costs, broken down by getting there, staying, eating, getting around, parks and activities, and extras, with a low to high range, the source and date behind every figure, and a confidence score. Works for city trips, all-inclusive resorts, cruises and theme parks. Figures come from Endless Travel Plans' verified price data and the observed fares and room rates of real family budgets, never live prices; follow calculator_url for live prices. Places ETP has no data for come back as unsupported rather than a guess.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | Month of travel, as a name ("July") or number ("7"). Defaults to about two months out. | |
| style | No | Travel style. Defaults to moderate. | |
| adults | Yes | Adults travelling. | |
| nights | Yes | Nights away. | |
| trip_type | No | city, all_inclusive, cruise or theme_park. Inferred from the destination when left out. | |
| destination | Yes | Where the family is going: a city ("Chicago"), a theme park ("Walt Disney World"), a beach area for an all-inclusive ("Cancun"), or a cruise ("Royal Caribbean Caribbean cruise"). | |
| children_ages | No | Age of each child, one entry per child (ages decide seats, tickets and meal prices). Empty for no children. | |
| departure_city | No | Home city or airport the family leaves from, for getting there. Without it, flights use a typical distance and say so. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent/non-destructive annotations by disclosing data provenance (verified ETP price data and observed real family budgets), a critical freshness caveat (never live prices), the failure mode for unsupported destinations, and that every figure carries a source, date, and confidence score.
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 and mostly free of padding, though the opening sentence is a long multi-clause run-on and the trip-type list partially repeats the trip_type enum already in the schema.
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 return-shape burden (cost categories, low-to-high range, per-figure source/date, confidence score) and the data-freshness caveat. The one gap is the bare reference to 'calculator_url', which is neither a parameter nor an explained output field, so an agent may not know where to find it.
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 all eight parameters (defaults for month and style, inference of trip_type, effect of departure_city, role of children_ages) are already documented in the schema. The description adds little per-parameter meaning beyond that baseline.
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 (estimate) and resource (family trip costs) and enumerates the exact cost breakdown the tool returns (getting there, staying, eating, getting around, parks, extras). No sibling tools exist, so no differentiation is required, but the scope is nonetheless unambiguous.
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 lists supported trip types (city, all-inclusive, cruise, theme park), the failure condition (places with no ETP data return 'unsupported' rather than a guess), and the alternative route for another need (follow calculator_url for live prices). When-to-use, when-not, and an alternative are all present.
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.
estimate_family_trip_budgetPlans a whole trip from a total budget, every price labelled live, estimate or official.
Trip planning for nomadic families: multi-stop trips, Schengen/visa, climate, destinations.
Estimate mobile-data needs and build a provider-neutral connectivity checklist for any trip.
A plain-language trip description becomes dated flight deals with prices and booking links.
Add one secure layer between your agents and this server.
