viajante

Overview Schema Source Related Servers Discussions Admin

Compare award to cash

compare_awards

Read-onlyIdempotent

Compare specific airline award offers directly to local cash prices. Verify the true monetary value of a named travel promotion against current market rates.

Instructions

Compare a named award offer to cash locally. Does not invent seats.

offer must include origin, destination, departure_date, program, points, and evidence. confirmed evidence needs a named source. Unnamed cash_price omits cpp_cents. Do not treat estimated or user_supplied as live inventory.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`offer`	Yes
`balances`	No
`currency`	No
`cash_price`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`status`	Yes
`empty_note`	Yes
`error_code`	Yes
`observed_at`	Yes
`retry_after`	Yes
`completeness`	Yes
`empty_reason`	Yes
`observed_at_basis`	Yes
`retry_after_seconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.5.2Oct 19, 2026

removedInput schema / properties / balances / title
```
Removed value: -"Balances"
```
removedInput schema / properties / cash_price / title
```
Removed value: -"Cash Price"
```
removedInput schema / properties / currency / title
```
Removed value: -"Currency"
```
removedInput schema / properties / offer / title
```
Removed value: -"Offer"
```

removedInput schema / title

Removed value: -"compare_awardsArguments"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "completeness": {
+      "enum": [
+        "complete",
+        "partial",
+        "blocked"
+      ],
+      "type": "string"
+    },
+    "empty_note": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "empty_reason": {
+      "anyOf": [
+        {
+          "enum": [
+            "provider_empty",
+            "filtered_out",
+            "not_loaded"
+          ],
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "error_code": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "observed_at": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "observed_at_basis": {
+      "anyOf": [
+        {
+          "enum": [
+            "provider",
+            "fetch"
+          ],
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "retry_after": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "retry_after_seconds": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "status": {
+      "enum": [
+        "ok",
+        "no_results",
+        "rate_limited",
+        "blocked",
+        "timeout",
+        "failed"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "completeness",
+    "empty_reason",
+    "empty_note",
+    "error_code",
+    "retry_after",
+    "retry_after_seconds",
+    "observed_at",
+    "observed_at_basis"
+  ],
+  "type": "object"
+}

Addedv1.4.1Oct 6, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: it computes locally, it 'does not invent seats', it distinguishes confirmed vs estimated/user_supplied evidence, and it discloses an output rule ('unnamed cash_price omits cpp_cents'). That is meaningful extra context, though it doesn't address edge cases like what happens with an invalid or unverifiable offer.

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?

Two tight paragraphs with the core purpose front-loaded and constraints following. The telegraphic style ('Does not invent seats', 'Unnamed cash_price omits cpp_cents') is dense but every clause adds a rule; no filler sentences.

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?

An output schema exists, so return-value detail is correctly omitted, and the description covers the complex nested input and evidence semantics that the schema can't express. It falls short only on balances/currency semantics and on how evidence tiers map to the resulting comparison, minor gaps for a read-only, idempotent tool.

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 coverage is 0% and the required 'offer' param is an opaque object with additionalProperties:true, so the description carries real weight by enumerating required offer keys (origin, destination, departure_date, program, points, evidence) and the evidence-source rule. It partially covers cash_price ('unnamed cash_price omits cpp_cents') but says nothing about balances or currency, leaving two of four parameters undocumented anywhere.

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+resource (compare a named award offer to cash) and adds a scope qualifier ('locally'), which tells the agent the computation is offline and no live inventory is fetched. No sibling tool in the list performs award-vs-cash comparison, so differentiation is implicit rather than stated, keeping this just short of a 5.

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?

It gives input-validity rules ('offer must include origin, destination, departure_date, program, points, and evidence', 'confirmed evidence needs a named source') and a caution ('Do not treat estimated or user_supplied as live inventory'), which implies when the tool is appropriate. However, it never says when to choose this over recheck_offer, verify_answer, or other siblings, so usage is inferred rather than instructed.

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