Vuelo Travel

The traveller's Vuelo bookings

list_my_bookings

For a traveller who wants to manage a booking here, in the chat, and does not have its reference: every booking on the mobile they booked with. Two calls. First pass the mobile alone (with country if it is not written with +): Vuelo texts that number a 6-digit code, and the answer is the same whether or not it has bookings. Ask the traveller for the code, then call again with the same mobile and the code: you get each booking's reference, what it is, its dates, its status (booked, reserved, cancelled, awaiting_payment, payment_link_expired), and the date to pay by or to cancel free by. Show them the list and ask which one. Then use get_booking, cancel_booking or request_change with that reference and this mobile. Never names, dates of birth or booking pages. If the code is not right, ask them to check the text; after five wrong tries, call again without the code for a new one.

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": {
      "mobile": "<mobile>"
    },
    "name": "list_my_bookings"
  }
}

Input Schema

Name	Required	Description
`code`	No	The 6-digit code Vuelo texted, once the traveller has read it out. Leave out on the first call.
`mobile`	Yes	The mobile the traveller booked with.
`country`	No	For a mobile typed the local way (06 12 34 56 78), the country it is from, as an ISO code (FR). Not needed for a number with +.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A4.3/5.0

Behavior5/5

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

The description adds substantial behavior beyond the annotations: the tool triggers an SMS with a 6-digit code, requires two calls, returns the same response whether or not bookings exist, and allows a fresh code after five wrong attempts. It also enumerates the returned booking statuses and date fields. These are exactly the side effects and edge cases an agent needs for a tool with readOnlyHint=false and openWorldHint=true.

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?

The description is front-loaded with the core purpose and the first-call instruction, then proceeds step by step. It is dense but nearly every sentence carries operational meaning. A few phrases are conversational and could be tightened, but nothing important is buried.

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, but the description compensates by specifying the returned fields (reference, booking type, dates, status values, payment/cancellation dates) and the next tools to call. It also covers OTP failure handling. An agent has enough to complete the workflow without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3. The description still adds real value by explaining when to omit code, how to handle country for locally formatted numbers, and that the same mobile plus code must be reused on the second call. That goes beyond the schema's field-level descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: list every booking on the traveller's mobile number without needing a booking reference. It is clear about the two-call OTP flow and what the output contains. It does not explicitly distinguish itself from the sibling find_my_booking, which an agent might reasonably confuse with this tool.

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?

It gives a clear when-to-use condition (the traveller wants to manage a booking in chat without a reference) and names the follow-up tools to use once a reference is obtained: get_booking, cancel_booking, request_change. It also includes exclusions ('Never names, dates of birth or booking pages') and a fallback for wrong codes. It stops short of explicitly comparing itself to find_my_booking or other search tools.

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

All Vuelo Travel tools Inspect

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

Need Help?