cwsi.net Fare Classes & Mileage Calculators

Avianca LifeMiles Calculator

calculate_avianca_lifemiles

Read-onlyIdempotent

Avianca LifeMiles for a flight operated by Avianca. LifeMiles = fare in US dollars (whole ticket, without taxes, fees and extras) x rate by fare family (Basic and Light 3, Classic 6, Flex 8, Business 10), plus an Elite bonus of that base (Red Plus 10%, Silver 20%, Gold 60%, Diamond 80%, Magno 100%), rounded down. Qualifying miles = the base LifeMiles plus 1 per 20 bonus LifeMiles. Progress toward Red Plus (6,000), Silver (12,000), Gold (24,000), Diamond (45,000) and Magno (110,000) qualifying miles in a calendar year; qm is the qualifying miles so far. Uses cwsi.net's calculator and the airline's published rules. Unofficial.

Input Schema

Name	Required	Description	Default
`qm`	No	Qualifying miles you have so far this year (optional). Used only for the progress toward the next Elite status.
`fare`	No	Fare family. BS = Basic (3 per $1, domestic flights); LT = Light (3 per $1, international flights); CL = Classic (6 per $1); FX = Flex (8 per $1); BZ = Business (10 per $1, Business Classic, Business Flex, INSIGNIA). Shown on your booking. Avianca does not publish booking class letters for its fare families.	CL
`price`	No	Fare paid (USD, whole ticket) in US dollars. In US dollars: the fare for the whole ticket without taxes, fees and additional services (bags, seats and other extras). Required unless creditTo is given.
`status`	No	Your LifeMiles Elite status when you fly. NO = No Elite status (no bonus); RP = Red Plus (10% bonus); SV = Silver (20% bonus); GD = Gold (60% bonus); DI = Diamond (80% bonus); MG = Magno (100% bonus).	NO
`creditTo`	No	Credit the flights to a partner program instead of Avianca's own: united = United MileagePlus (creditStatus one of: General member, Premier Silver, Premier Gold, Premier Platinum, Premier 1K); aeroplan = Aeroplan (creditStatus one of: Aeroplan Member, 25K, 35K, 50K, 75K, Super Elite). Earns by each flight's distance and the booking class at the program's published partner rates; leave creditTo out for the airline's own program. Give the booking class letter as creditClass. Give the flights as creditFlights (one entry per flight with its great-circle miles). No price is needed with creditTo.
`creditClass`	No	The booking class letter on the ticket, for creditTo (required with creditTo). Ignored without creditTo.
`creditStatus`	No	Your status in the creditTo program, by its name as listed under creditTo. Defaults to the base level. Ignored without creditTo.
`creditFlights`	No	The flights for creditTo: one entry per one-way flight, in order, with its great-circle miles (calculate_flight_distance gives them) and optionally from/to airport codes. Defaults to segs when they carry miles.

Output Schema

Name	Required	Description	Default
`link`	Yes
`notes`	Yes
`inputs`	Yes
`airline`	Yes
`headline`	Yes
`progress`	No
`breakdown`	Yes
`calculator`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 13, 2026

addedInput schema / properties / creditClass

Added value: +{
+  "description": "The booking class letter on the ticket, for creditTo (required with creditTo). Ignored without creditTo.",
+  "pattern": "^[A-Za-z]$",
+  "type": "string"
+}

addedInput schema / properties / creditFlights

Added value: +{
+  "description": "The flights for creditTo: one entry per one-way flight, in order, with its great-circle miles (calculate_flight_distance gives them) and optionally from/to airport codes. Defaults to segs when they carry miles.",
+  "items": {
+    "properties": {
+      "from": {
+        "description": "The departure airport's code; labels the breakdown.",
+        "pattern": "^[A-Za-z0-9]{3,4}$",
+        "type": "string"
+      },
+      "miles": {
+        "description": "Great-circle distance of this flight in miles.",
+        "maximum": 12500,
+        "minimum": 1,
+        "type": "integer"
+      },
+      "to": {
+        "description": "The arrival airport's code; labels the breakdown.",
+        "pattern": "^[A-Za-z0-9]{3,4}$",
+        "type": "string"
+      }
+    },
+    "required": [
+      "miles"
+    ],
+    "type": "object"
+  },
+  "maxItems": 8,
+  "minItems": 1,
+  "type": "array"
+}

addedInput schema / properties / creditStatus

Added value: +{
+  "description": "Your status in the creditTo program, by its name as listed under creditTo. Defaults to the base level. Ignored without creditTo.",
+  "maxLength": 64,
+  "type": "string"
+}

addedInput schema / properties / creditTo

Added value: +{
+  "description": "Credit the flights to a partner program instead of Avianca's own: united = United MileagePlus (creditStatus one of: General member, Premier Silver, Premier Gold, Premier Platinum, Premier 1K); aeroplan = Aeroplan (creditStatus one of: Aeroplan Member, 25K, 35K, 50K, 75K, Super Elite). Earns by each flight's distance and the booking class at the program's published partner rates; leave creditTo out for the airline's own program. Give the booking class letter as creditClass. Give the flights as creditFlights (one entry per flight with its great-circle miles). No price is needed with creditTo.",
+  "enum": [
+    "united",
+    "aeroplan"
+  ],
+  "type": "string"
+}

changedInput schema / properties / price / description

Previous value: -"Fare paid (USD, whole ticket) in US dollars. In US dollars: the fare for the whole ticket without taxes, fees and additional services (bags, seats and other extras)."New value: +"Fare paid (USD, whole ticket) in US dollars. In US dollars: the fare for the whole ticket without taxes, fees and additional services (bags, seats and other extras). Required unless creditTo is given."

removedInput schema / required
```
Removed value: -[
-  "price"
-]
```

AddedOct 13, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description adds meaningful domain context beyond them: the full earning formula, rounding-down behavior, elite bonus percentages, qualifying-mile thresholds, the credit-card-partner alternative via creditTo, and the 'Unofficial' caveat with its data source (cwsi.net plus published rules).

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

Conciseness3/5

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

The opener is front-loaded and clear, but the body collapses into a long, dense run-on of formulas, percentages and thresholds. Most content is necessary for a calculator, yet it could be structured far more readably (bullets/steps) for the same information.

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 an output schema exists and parameter coverage is complete, the description needn't explain returns and doesn't. It supplies the domain logic (formula, bonuses, thresholds, partner-credit path) an agent needs to invoke it correctly, falling just short of explicitly tying each branch of the model to the input parameters it consumes.

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 100%, so the schema already documents every parameter (qm, fare, price, status, creditTo, creditClass, creditStatus, creditFlights). The description largely restates the fare-family rates and elite bonuses that the schema enum descriptions already carry, so it adds little semantic meaning beyond the structured fields.

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+resource (calculates Avianca LifeMiles) and scopes eligibility ('for a flight operated by Avianca'). An agent can immediately distinguish it from the ~50 sibling airline calculators by the airline and the exact earning model it exposes.

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 implies usage (pass fare/price/status, or creditTo to redirect to a partner) and references calculate_flight_distance for miles, but never states when to prefer this tool or when not to use it. No explicit when/alternatives guidance against the sibling set.

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

All cwsi.net Fare Classes & Mileage Calculators 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?