Skip to main content
Glama
Sign In

Vuelo Travel

by com.getvuelo
OverviewDiscussionsAdmin

Where a Vuelo booking stands

get_booking
Read-onlyIdempotent

For a booking made in another conversation, or through another assistant: where it stands, by its Vuelo reference (VU-...) and the email or mobile it was booked with. Says booked, reserved, cancelled, cancellation_in_progress or not_booked, with the item, dates, number of travellers, amount, free cancellation date, the stay (hotel, area, stars, room, nights, what is included, any tax paid at the hotel, and a public page about the hotel), the date a reservation must be paid by, any requests with Vuelo's team, and its history oldest first (booked or reserved, cancellation_requested, cancelled, refund_sent, request_raised, team_replied, changed with what changed, request_resolved). It never gives names, dates of birth or the booking page: to give the traveller their page, use find_my_booking. If nothing matches, say the details did not match a booking and ask them to check the reference and the email or mobile; never say which was wrong. For a booking made in this conversation, use get_booking_status.

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": {
      "reference": "<reference>"
    },
    "name": "get_booking"
  }
}

Input Schema

NameRequiredDescriptionDefault
emailNoThe email the traveller booked with.
mobileNoOr the mobile on the booking, instead of the email.
referenceYesThe Vuelo booking reference, VU-...

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/closed-world, but the description adds what actually comes back: status vocabulary, item, dates, travellers, amount, free cancellation date, hotel detail, payment deadline, requests, and history ordering. It also discloses a real constraint beyond the schema — it withholds names, dates of birth and the booking page — and dictates the no-match handling, which no annotation conveys.

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?

Purpose and the sibling routing are front-loaded, and every element listed is information an agent would otherwise lack. It loses a point for being one sprawling sentence whose long enumerations of statuses and hotel fields are harder to scan than a short structured list.

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?

There is no output schema, so the description carries the full burden of describing return values — and it does, enumerating status values, booking detail, hotel fields, payment deadline, requests, and history entries with ordering. Combined with the privacy boundary and the no-match behavior, an agent has everything needed to call and interpret it.

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 three parameters including the email-or-mobile alternative and the VU- reference format. The description reinforces that reference and contact detail are required together but adds no syntax or constraint beyond what the schema states; baseline 3 applies.

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 resource and scope: the status of a Vuelo booking looked up by reference plus the email or mobile it was made with. It immediately distinguishes itself from get_booking_status (bookings made in this conversation) and find_my_booking (giving the traveller their page).

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 about when to use it ('a booking made in another conversation, or through another assistant') and names both alternatives with the condition that selects them. It also prescribes the failure path — say details did not match, ask them to check both reference and email/mobile, never say which was wrong.

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