Skip to main content
Glama

Vuelo Travel

by com.getvuelo
OverviewDiscussionsAdmin

Search Vuelo trips

search_trips
Read-onlyIdempotent

Find hotels, flights and flight-and-hotel packages on Vuelo for a destination, dates and number of travellers, within a budget. The results appear in the Vuelo card, where the traveller compares and books them: do not follow up with a question asking which one they want. Hotels are live; pass origin and destinationAirport (IATA codes) to include flights and packages. Flight fares are live and ticketed at purchase. Pass cabin for premium economy, business or first. Returns prices, photos and the payment options Vuelo offers for each trip. Show payment options exactly as returned and always show the full price. Call it ONCE for what the traveller asked: every call shows another Vuelo card in the chat. Do not run extra searches for other towns, dates or budgets on your own; if the request is broad ("somewhere near London"), pick the best single destination or ask the traveller, and search again only when they ask for something different.

Input Schema

NameRequiredDescriptionDefault
toYesCheck-out or return date, YYYY-MM-DD. For a one-way flight, give the same date as from.
fromYesCheck-in date, YYYY-MM-DD
onlyNoWhat the traveller asked for. Set "flights" whenever they ask for flights and not a hotel (for example "find me flights to Nice"), "stays" for a hotel only, "packages" for flight and hotel together. Only leave it out when they want to see everything. Never add hotels to a flights request.
cabinNoWhich cabin to price flights in, when the traveller asks for one ("business class", "premium economy", "first"). Economy when not said. Only affects flights and packages.
hotelNoThe hotel, when the traveller names one ("the Pulitzer", "The Savoy"): its name only, with the town in destination. Vuelo finds it by name and lists it first, with other hotels in the town after it. Never use minStars or a budget to stand in for a named hotel.
budgetNoMaximum total in pounds
mobileNoThe traveller's mobile number (any country; international format such as +1 415 555 2671 outside the UK), whenever you already know it from this conversation or about the user. Always pass it if you have it: when they tap Book in the Vuelo card, Vuelo texts the secure link straight to it, so they type nothing. Vuelo keeps it for this conversation only and never shows it in the chat. Do not ask for it just to search.
originNoWhere they fly from, to include live flights and packages: an airport code (LHR) or, when the traveller names a city, the city (London, or LON), which searches every airport there (Heathrow, Gatwick, Stansted, Luton, City). Pass the city unless they named one airport. Ask where they are flying from if they want flights.
minStarsNoMinimum hotel star rating, when the traveller asks for one (for example 5 for "5-star").
travellerNoThe person booking, whenever you know them from this conversation or about the user: full name as on their ID, email, date of birth (YYYY-MM-DD) and home postcode. Vuelo keeps them for this conversation, so when the traveller taps Book in the card they have nothing to type. Never guess any of it.
passengersNoPass this whenever you know it: the results page and checkout then need nothing typed. Who is flying, if the traveller has already told you or you know it: full names as on the passport, and dates of birth if you have them. Vuelo fills these into the booking form so they are not asked for again. Names alone still help. This is who is flying; travellers above is how many.
travellersYesNumber of travellers
destinationYesTown or city, with its country when the name is shared or could be ambiguous: "Lisbon", "Zurich, Switzerland", "Cambridge, UK". A region (the Cotswolds) cannot be searched: use one town in it.
refundableOnlyNoOnly stays with a refundable rate, when the traveller asks for refundable or free cancellation. Flights are ticketed at booking, so none are refundable.
destinationAirportNoArrival airport for the destination, for example LIS for Lisbon; for a city with several airports (London, Paris, New York, Milan, Rome, Tokyo, Stockholm) pass the city to search them all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Goes well past the readOnly/idempotent annotations: it discloses that each call renders a new Vuelo card in the chat, that the traveller books from that card so no follow-up question is needed, that hotel and flight data are live and fares are ticketed at purchase, and that payment options must be shown verbatim with full prices. Missing only rate/latency or result-count behavior, which is minor for a search.

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, then constraints in a sensible order. It is dense and mostly earns its length, though the 'do not follow up with a question' and 'call it ONCE / another Vuelo card' instructions overlap slightly and the payment-display rules are repeated in spirit.

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 15-parameter open-world search with nested objects and no output schema, the description covers what comes back (prices, photos, payment options), where it appears (the card), freshness of data, and the behavioural contract around repeat calls. Nothing an agent needs to invoke it correctly is missing.

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 all 15 parameters in detail and the baseline applies. The description adds a little genuine meaning — the origin/destinationAirport pairing that unlocks flights and packages, and that cabin only affects flights and packages — but it does not explain most parameters beyond what the schema says.

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?

States a specific verb (find) plus the three resource types (hotels, flights, packages) and the scoping inputs (destination, dates, travellers, budget). It is clearly separable from siblings like get_hotel_availability (availability lookup for one property) and book_trip (the conversion step that follows the card).

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

Usage Guidelines5/5

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

Explicit when-to-use and when-not: call it ONCE for what the traveller asked, do not run extra searches for other towns/dates/budgets, search again only when they ask for something different, and pick one destination or ask when the request is broad. It also gives the conditional rule for including flights (pass origin and destinationAirport) versus stays only.

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

All Vuelo Travel toolsInspect
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