Skip to main content
Glama

Vuelo Travel

by com.getvuelo
OverviewDiscussionsAdmin

Cancel a Vuelo booking

cancel_booking
DestructiveIdempotent

Cancel a Vuelo booking, before or after the traveller confirms. Pass the taskId if it was made in this conversation; from any other conversation, a made booking can be cancelled with its Vuelo reference (VU-...) and the email or mobile it was booked with. Not confirmed yet: it is called off at once, the texted link stops working and nothing was charged. Already booked: call it first with preview: true and tell the traveller what they would get back (refund.amount, summary). If they want to go ahead, call it again without preview. A reservation with nothing paid is cancelled at once. For anything paid, Vuelo texts the traveller a six-digit code and nothing is cancelled until it is given: ask them for it and call again with code (they can also enter it on their booking page). Never guess a code, and never say a paid booking is cancelled until this or get_booking_status says so.

Input Schema

NameRequiredDescriptionDefault
codeNoFor a paid booking: the six-digit code Vuelo texted the traveller, as they gave it to you. Finishes the cancellation and the refund.
emailNoWith reference: the email the traveller booked with.
mobileNoWith reference, instead of email: the mobile on the booking.
taskIdNoThe taskId book_trip returned, when the booking was made in this conversation.
previewNotrue: only say what cancelling would refund, changing nothing.
referenceNoOtherwise: the Vuelo booking reference (VU-...).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructive/openWorld/idempotent, but the description adds real operational context beyond them: the texted link stops working, nothing was charged if unconfirmed, unpaid confirmed reservations cancel immediately, paid ones require a six-digit code and nothing is cancelled until it is supplied. It also warns not to claim a paid booking is cancelled until this tool or get_booking_status confirms it.

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?

Dense and front-loaded: identity resolution comes first, then the unconfirmed case, then the confirmed/paid flow. It runs long, but for a multi-step destructive flow nearly every sentence carries a distinct constraint; a tighter edit would still help.

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, and the description compensates by naming the preview return fields (refund.amount, summary) and stating the confirmation source of truth. Nothing an agent needs to call this safely is missing.

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 100%, so the baseline is 3, but the description adds conditional pairing logic the schema states only piecemeal: taskId is the in-conversation path, while reference requires email or mobile as an alternative identifier. The preview and code semantics are restated with the sequencing that makes them actionable.

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 and resource ("Cancel a Vuelo booking") plus the scope that matters most ("before or after the traveller confirms"). This clearly separates it from read-only siblings like get_booking_status and find_my_booking.

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 routing: pass taskId when the booking came from this conversation, otherwise reference (VU-...) plus the email or mobile used to book. It also prescribes a two-step protocol for confirmed bookings (call with preview: true first, then without) and a code step for paid bookings, with a hard exclusion ("Never guess a code").

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