Skip to main content
Glama

cwsi.net Fare Classes & Mileage Calculators

JetBlue TrueBlue Calculator

calculate_jetblue_points
Read-onlyIdempotent

Estimate what a JetBlue 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

NameRequiredDescriptionDefault
cardNoPaying with a JetBlue card. none = No; JB = JetBlue Card (+3 per $1); JP = Plus (+6 per $1); JBZ = Business (+6 per $1); JPR = Premier (+6 per $1).none
fareNoFare. base = Base (1 per $1); standard = Standard (3 per $1); flex = Flex (3 per $1). Every cabin is sold as Base, Standard or Flex.standard
cabinNoCabin. main = Main; evenmore = EvenMore; bluefirst = BlueFirst; mint = Mint.main
priceYesFare paid (before taxes and fees) in US dollars. Points and tiles are earned on the fare before taxes and fees.
directNoBooked on jetblue.com or the app. 1 = Yes; 0 = No (Travel agent or other site). Booking direct earns the same points again.1
statusNoYour TrueBlue status. General Member = General Member (No status); Mosaic 1 = Mosaic 1 (+3 per $1); Mosaic 2 = Mosaic 2 (+3 per $1); Mosaic 3 = Mosaic 3 (+4 per $1); Mosaic 4 = Mosaic 4 (+5 per $1).General Member

Output Schema

NameRequiredDescriptionDefault
linkYes
notesYes
inputsYes
airlineYes
headlineYes
progressNo
breakdownYes
calculatorYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / cabin / description
      Previous value: -"Cabin. main = Main; evenmore = EvenMore; mint = Mint."New value: +"Cabin. main = Main; evenmore = EvenMore; bluefirst = BlueFirst; mint = Mint."
    • changedInput schema / properties / cabin / enum
      Previous value: -[
      -  "main",
      -  "evenmore",
      -  "mint"
      -]New value: +[
      +  "main",
      +  "evenmore",
      +  "bluefirst",
      +  "mint"
      +]
    • changedInput schema / properties / fare / description
      Previous value: -"Fare. base = Base (1 per $1); standard = Standard (3 per $1); flex = Flex (3 per $1). Only applies to some choices of the other fields; ignored otherwise."New value: +"Fare. base = Base (1 per $1); standard = Standard (3 per $1); flex = Flex (3 per $1). Every cabin is sold as Base, Standard or Flex."
    • removedInput schema / properties / mfare
      Removed value: -{
      -  "default": "standard",
      -  "description": "Fare. standard = Standard (3 per $1); flex = Flex (3 per $1). Mint is sold as Standard or Flex. No Base fare in Mint. Only applies to some choices of the other fields; ignored otherwise.",
      -  "enum": [
      -    "standard",
      -    "flex"
      -  ],
      -  "type": "string"
      -}
  2. Changed1 schema field changed
    • addedInput schema / properties / price / maximum
      Added value: +1000000
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive behavior, and a closed-world scope. The description adds meaningful context beyond those annotations by calling the result an estimate, citing cwsi.net and published airline rules, and labeling the tool 'Unofficial.'

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 a single front-loaded sentence with no redundant material. It efficiently covers the estimate, the earning dimensions, the source, and the unofficial caveat.

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?

With a fully documented schema, an output schema, and safety annotations, the description provides enough context to invoke the tool correctly. The only minor gap is that it does not explicitly frame usage relative to sibling fare/distance tools.

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 six parameters are already documented with enums and meanings. The description adds no parameter-level detail beyond what the schema provides, which is sufficient for a baseline score of 3.

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 states a specific verb and resource: estimate what a JetBlue ticket earns in miles/points and status credit. The airline-specific name and the mention of JetBlue TrueBlue rules distinguish it from the many sibling calculators without needing to inspect the schema.

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 intended use is implied by 'Estimate what a JetBlue ticket earns,' but there is no explicit when-to-use guidance or comparison to alternatives such as calculate_flight_distance or compare_fare_classes. 'Unofficial' is a useful caveat, yet no exclusions or prerequisites are given.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources