upgrade-agent

Start Booking Watch

start_watch

Set up a Watcher Concierge: have Upgrade Agent CONTINUOUSLY watch a traveler's booking between now and departure and surface improvements to their trip — a better seat (even window-vs-middle), an empty adjacent seat, a cabin upgrade, lounge, or fast track — acting within a budget or notifying them. Gather the traveler's ORDERED preferences, then call this. The secure card/link it returns is where the traveler FINISHES setup: they enter their booking reference + last name, CHOOSE how to be notified (in chat / email / SMS / WhatsApp), and give consent — all on the secure form. So do NOT ask for their PNR, email, phone, or consent in the chat. Afterward, use get_watch_status to check it.

Input Schema

TableJSON Schema

Name	Required	Description
`carrier`	No	Airline/operator name or IATA code if known.
`contact`	No
`purpose`	No	Is the trip for business or leisure? Tailors the complementary experiences we surface at the destination.
`channels`	No	How to reach them: in_chat \| watch_page \| email \| sms \| whatsapp \| push.
`autoAction`	No	If true (and a budget is set), act within budget; else notify.
`firstVisit`	No	Is this the traveler's first time at the destination? Biases toward the classics vs off-the-beaten-path.
`preferences`	Yes	The traveler's improvements to watch for, in their order of preference.
`budgetAmount`	No	Overall budget if they want the agent to act.
`budgetCurrency`	No

Output Schema

TableJSON Schema

Name	Required	Description
`token`	No	Watch token — pass to get_watch_status.
`carrier`	No
`setupUrl`	No	Secure link where the traveler activates the watch.
`watchUrl`	No	Public watch page (status + timeline).
`carrierIata`	No
`carrierLogo`	No
`carrierName`	No
`preferences`	No
`carrierAccent`	No

TDQS

A4.3/5.0

Behavior4/5

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

The description adds behavioral context beyond annotations, such as the return of a secure link/card for traveler setup and the continuous nature of the watch. It does not contradict annotations, though it could mention idempotency or side effects of multiple calls.

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 reasonably concise and front-loaded with the main action, but it is somewhat lengthy. It is structured well with clear instructions, though a few sentences could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (9 parameters, nested objects, output schema), the description covers the core purpose, usage guidelines, and post-call action. It mentions the output is a secure link/card, which is sufficient. The schema handles detailed parameter explanations.

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?

The schema already covers 78% of parameters with descriptions. The description adds value by emphasizing that preferences should be ordered, but does not significantly extend parameter semantics beyond the schema.

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?

The description clearly states the tool's purpose: setting up a Watcher Concierge to continuously watch a booking and surface improvements. It uses a specific verb-resource combination ('Set up a Watcher Concierge') and distinguishes itself from sibling tools like get_watch_status.

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?

The description provides explicit guidance on when to use the tool: after gathering the traveler's ordered preferences. It also instructs what not to do ('do NOT ask for their PNR, email, phone, or consent in the chat') and suggests a follow-up action ('use get_watch_status to check it').

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

All upgrade-agent tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct function or workflow step (e.g., general info vs booking-specific check, bid placement vs bid status, partner lookup vs pricing), and descriptions clarify when to use which. Even overlapping actions like check_upgrade_eligibility and start_eligibility_check are clearly differentiated by context.

Naming Consistency4/5

Most tools follow a verb_noun pattern (e.g., check_upgrade_eligibility, place_bid, get_bid_status). A few deviate slightly (partner_question_insights, usage_totals) but the naming is still intuitive and readable overall.

Tool Count4/5

17 tools is at the upper end of typical but still well-scoped given the breadth of functionalities (eligibility, bidding, watch, partner info, analytics). Every tool has a clear purpose, so the count feels justified rather than bloated.

Completeness4/5

The tool set covers the full lifecycle of upgrade management: eligibility check, bid placement/modification/status, pricing, partner info, watch, and system metrics. A minor gap is the absence of a cancel bid tool, but the main workflows are complete.

Resources

Need Help?