upgrade-agent

Start Booking Watch

start_watch

Sets up a Watcher that monitors a traveler's booking between now and departure for upgrade opportunities (a better seat, an empty adjacent seat, a cabin upgrade, lounge, or fast track). Returns a secure card/link where the traveler enters their booking, notification preference, and consent.

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 22, 2026

changedOutput schema / (root)

Previous value: -{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "additionalProperties": false,
-  "properties": {
-    "carrier": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "carrierAccent": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "carrierIata": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "carrierLogo": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "carrierName": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "preferences": {
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "rank": {
-            "type": "number"
-          },
-          "type": {
-            "type": "string"
-          }
-        },
-        "required": [
-          "type",
-          "rank"
-        ],
-        "type": "object"
-      },
-      "type": "array"
-    },
-    "setupUrl": {
-      "description": "Secure link where the traveler activates the watch.",
-      "type": "string"
-    },
-    "token": {
-      "description": "Watch token — pass to get_watch_status.",
-      "type": "string"
-    },
-    "watchUrl": {
-      "description": "Public watch page (status + timeline).",
-      "type": "string"
-    }
-  },
-  "type": "object"
-}New value: +null

Changed2 schema fields changedJul 8, 2026

addedInput schema / properties / firstVisit

Added value: +{
+  "description": "Is this the traveler's first time at the destination? Biases toward the classics vs off-the-beaten-path.",
+  "type": "boolean"
+}

addedInput schema / properties / purpose

Added value: +{
+  "description": "Is the trip for business or leisure? Tailors the complementary experiences we surface at the destination.",
+  "enum": [
+    "business",
+    "leisure"
+  ],
+  "type": "string"
+}

Changed9 schema fields changedJul 8, 2026

changedInput schema / properties / channels / description

Previous value: -"How to reach them: in_chat | watch_page | email | whatsapp | push."New value: +"How to reach them: in_chat | watch_page | email | sms | whatsapp | push."

addedInput schema / properties / contact / properties / phone

Added value: +{
+  "description": "Mobile number for SMS (E.164, e.g. +14155551234).",
+  "type": "string"
+}

addedOutput schema / properties / carrier

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / carrierAccent

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / carrierIata

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / carrierLogo

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / carrierName

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / preferences

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "rank": {
+        "type": "number"
+      },
+      "type": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "type",
+      "rank"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / watchUrl

Added value: +{
+  "description": "Public watch page (status + timeline).",
+  "type": "string"
+}

Changed1 schema field changedJul 2, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "setupUrl": {
+      "description": "Secure link where the traveler activates the watch.",
+      "type": "string"
+    },
+    "token": {
+      "description": "Watch token — pass to get_watch_status.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedJul 2, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations are all false, so the description carries the full burden. It states the tool sets up a watcher (a creation action) and returns a secure card/link, which gives some behavioral insight. However, it does not disclose idempotency, destructive side effects, authentication requirements, or what happens on repeated calls. It is not contradictory but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of two sentences. It front-loads the main purpose and then provides examples and the output. There is no wasted wording.

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

Completeness3/5

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

The tool has 9 parameters, nested objects, and no output schema. The description gives a high-level overview but does not explain parameter semantics or the return value in detail (only mentions a card/link). The schema handles most details, but the description could offer more on what happens after starting the watch, such as how to interact with 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 description coverage is 78%, which is above 50%, so baseline is 3. The description adds no additional parameter meaning beyond the schema. It does not explain any parameters or their interplay, relying entirely on 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 action: 'Sets up a Watcher that monitors a traveler's booking between now and departure for upgrade opportunities' with specific examples. It distinguishes from siblings like start_eligibility_check and get_watch_status by focusing on monitoring for upgrades. The verb 'sets up' and resource 'Watcher' are specific.

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

Usage Guidelines3/5

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

The description provides clear context on what the tool does but does not explicitly mention when to use it versus alternatives or any exclusions. There is no mention of 'use start_eligibility_check for eligibility' or when not to use this tool. It gives context but no routing guidance.

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

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?