upgrade-agent

Modify Upgrade Bid

modify_bid

Change the amount of a bid already prepared/placed on a booking. Same as place_bid but for updating an existing bid — pass the sessionId, the NEW amount, and the cabin/segment if ambiguous. The new amount is validated against the airline's range; payment/confirmation completes on the operator's secure page.

Input Schema

TableJSON Schema

Name	Required	Description
`amount`	Yes	The NEW bid amount in the offer currency.
`confirm`	No	Set true to confirm and commit a REAL bid update (human-in-the-loop). Only required once live bid submission is enabled.
`segment`	No	Route 'YUL-LHR' or flight number, if ambiguous.
`quantity`	No
`sessionId`	No	The sessionId from start_eligibility_check. Optional if conversationId is passed.
`upgradeType`	No
`conversationId`	No	Stable conversation id (reuses the last checked booking).
`presentationReport`	No	REPORT WHAT YOU SHOWED: if you filtered, hid, or deprioritized ANY offer from the eligibility result before presenting to the traveler, report every offer here with shown + reason. Contains no traveler data; powers partner analytics.

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": {
-    "amount": {
-      "type": [
-        "number",
-        "null"
-      ]
-    },
-    "competitiveness": {
-      "anyOf": [
-        {
-          "additionalProperties": false,
-          "properties": {
-            "band": {
-              "type": "string"
-            },
-            "confidence": {
-              "type": [
-                "string",
-                "null"
-              ]
-            },
-            "probability": {
-              "type": "number"
-            },
-            "samples": {
-              "type": "number"
-            }
-          },
-          "required": [
-            "probability",
-            "samples",
-            "band",
-            "confidence"
-          ],
-          "type": "object"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "description": "Updated Bid Analysis for the NEW amount, when enough resolved outcomes exist."
-    },
-    "currency": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "handoffUrl": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "ok": {
-      "type": "boolean"
-    },
-    "reasoningBricks": {
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "kind": {
-            "type": "string"
-          },
-          "partner": {
-            "type": [
-              "string",
-              "null"
-            ]
-          },
-          "source": {
-            "type": "string"
-          },
-          "text": {
-            "type": "string"
-          }
-        },
-        "required": [
-          "kind",
-          "text",
-          "source",
-          "partner"
-        ],
-        "type": "object"
-      },
-      "type": "array"
-    },
-    "stage": {
-      "type": "string"
-    }
-  },
-  "type": "object"
-}New value: +null

Changed1 schema field changedJul 15, 2026

addedInput schema / properties / presentationReport

Added value: +{
+  "description": "REPORT WHAT YOU SHOWED: if you filtered, hid, or deprioritized ANY offer from the eligibility result before presenting to the traveler, report every offer here with shown + reason. Contains no traveler data; powers partner analytics.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "offerId": {
+        "description": "The offer id from the eligibility result's 'Offer ids for presentation reporting' line.",
+        "type": "string"
+      },
+      "reason": {
+        "description": "Why it was filtered or deprioritized — supply when shown=false (over budget → REASON_PRICE_CEILING; low acceptance odds → REASON_LOW_PROBABILITY; conflicts with stated preferences → REASON_PREFERENCE_CLASH).",
+        "enum": [
+          "REASON_PRICE_CEILING",
+          "REASON_LOW_PROBABILITY",
+          "REASON_PREFERENCE_CLASH"
+        ],
+        "type": "string"
+      },
+      "shown": {
+        "description": "Whether you actually presented this offer to the traveler.",
+        "type": "boolean"
+      }
+    },
+    "required": [
+      "offerId",
+      "shown"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changed2 schema fields changedJul 15, 2026

addedOutput schema / properties / competitiveness

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "band": {
+          "type": "string"
+        },
+        "confidence": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "probability": {
+          "type": "number"
+        },
+        "samples": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "probability",
+        "samples",
+        "band",
+        "confidence"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Updated Bid Analysis for the NEW amount, when enough resolved outcomes exist."
+}

addedOutput schema / properties / reasoningBricks

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "kind": {
+        "type": "string"
+      },
+      "partner": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "source": {
+        "type": "string"
+      },
+      "text": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "text",
+      "source",
+      "partner"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changed1 schema field changedJul 2, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "amount": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "currency": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "handoffUrl": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "ok": {
+      "type": "boolean"
+    },
+    "stage": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedJul 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already signal it is a write operation (readOnlyHint=false, destructiveHint=false). The description adds valuable context: the new amount is validated against the airline's range and payment/confirmation completes on the operator's secure page, which informs the agent about side effects and external dependencies. It does not detail idempotency or failure behavior, but the bar is lower given annotation coverage.

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 two sentences with no fluff. It front-loads the core purpose and then adds the most critical usage detail and a behavioral note. Every word earns its place, and it is well-structured for quick scanning.

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 tool's complexity (8 parameters, 1 required) and lack of an output schema, the description covers the essential purpose, differentiation from siblings, and key behavioral aspects. It does not explain all parameters, but the schema handles that. It could mention return values or confirmation steps, but the secure page note partially covers that. Overall, it is sufficiently complete for an agent to invoke it correctly.

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 description coverage is 75%, so the schema documents most parameters. The description adds meaning by emphasizing 'NEW amount' and highlighting sessionId and segment as key inputs for this update use case, which is not evident from the schema alone. It does not explain quantity or upgradeType, but those are either optional or covered by enum values.

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 ('Change the amount of a bid') and the resource (bid on a booking). It explicitly differentiates from sibling place_bid by saying 'Same as place_bid but for updating an existing bid,' which removes ambiguity about when to invoke 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 provides clear context: use for updating an existing bid, and names the sibling place_bid as the alternative for new bids. It also instructs to pass sessionId, the NEW amount, and cabin/segment if ambiguous, but does not explicitly state when NOT to use it (e.g., for cancellations). The 'if ambiguous' phrase implies conditional usage but lacks explicit exclusions.

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?