cwsi.net Fare Classes & Mileage Calculators

United MileagePlus Calculator

calculate_united_miles

Read-onlyIdempotent

Estimate what a United Airlines ticket earns (miles or points, and status credit where it applies), using cwsi.net's calculator and the airline's published rules. Unofficial.

Input Schema

Name	Required	Description	Default
`card`	No	Paying with a United card. none = No; CM = Cardmember (+3 per $1); EX = Explorer (+6 per $1); QU = Quest (+7 per $1); CL = Club (+8 per $1); GW = Gateway (+5 per $1); DB = Gateway Debit (+4 per $1). Cardmember is a United card that you are not paying with.	none
`fare`	No	Fare type. ST = Standard (Economy and above); BE = Basic Economy.	ST
`price`	No	Ticket price (fare plus carrier-imposed charges, without government taxes) in US dollars. Shown on your receipt as the fare plus carrier-imposed charges. Required unless creditTo is given.
`status`	No	Your MileagePlus status. none = General (No status); PS = Silver; PG = Gold; PP = Platinum; 1K = 1K.	none
`flights`	No	Flights on this ticket. Each flight (segment) earns 1 PQF. Basic Economy earns none.
`creditTo`	No	Credit the flights to a partner program instead of United Airlines's own: 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 United Airlines's own: 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": [
+    "aeroplan"
+  ],
+  "type": "string"
+}

changedInput schema / properties / price / description

Previous value: -"Ticket price (fare plus carrier-imposed charges, without government taxes) in US dollars. Shown on your receipt as the fare plus carrier-imposed charges."New value: +"Ticket price (fare plus carrier-imposed charges, without government taxes) in US dollars. Shown on your receipt as the fare plus carrier-imposed charges. Required unless creditTo is given."

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

Changed1 schema field changedOct 9, 2026
- addedInput schema / properties / price / maximum
```
Added value: +1000000
```
First observedOct 5, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover the read-only/idempotent safety profile, so the bar is lower; the description adds genuine context by disclosing the data source ('cwsi.net's calculator and the airline's published rules') and flagging it as 'Unofficial', a caveat structured fields cannot convey. It stops short of stating accuracy limits or the dual United-vs-partner crediting mode.

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?

Two tight sentences, no redundancy, with the core action front-loaded and the 'Unofficial' caveat closing it out. Every clause earns its place.

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?

An output schema exists so return values needn't be explained, and the schema carries all nine parameters. However, for a tool with a meaningful partner-crediting mode (creditTo=Aeroplan) and a dependency on calculate_flight_distance, the description never surfaces either, leaving the agent to discover them from the schema alone.

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 all nine parameters (including the enums and the creditTo nested structure) are already documented in the schema. The description adds no format or semantics beyond what the schema provides; baseline 3 applies.

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 ('Estimate') and resource ('what a United Airlines ticket earns') and enumerates the outputs (miles/points, status credit). Among a family of ~50 parallel airline calculators, naming United makes the intended sibling unambiguous.

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 airpline name and 'ticket earns' framing imply when to pick this over the other calculate_* tools, but there is no explicit when/when-not guidance, no mention of the creditTo partner path, and no pointer to calculate_flight_distance for the distance inputs it needs. Usage is inferable but not stated.

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?