Airfare Brain

True cost

true_cost

Read-onlyIdempotent

The true cost of a flight on one airline. Pass fare (the total for the whole party, from a flight-search tool or the person) to get fare + extras; without it you get the extras alone. Extras = what the person chooses (cabin bag, checked bag by kg, seat, priority, infants) for their party and trip, as the range the airline publishes. Also lists what costs more if left until the airport, unchosen fees that may apply (admin, card %), and extras the airline does not publish a price for.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "airline": "<airline>"
    },
    "name": "true_cost"
  }
}

Input Schema

Name	Required	Description
`fare`	No	Total fare already found for the whole party, if known
`seat`	No	extra = legroom / front
`trip`	No	one_way (default) or return: return counts each extra on both flights
`airline`	Yes	Name or IATA code
`infants`	No	Under-2s on a lap
`currency`	No	Currency of the answer: EUR (default) or GBP, as the airline publishes it
`domestic`	No	true for a flight within the US: US airlines charge different bag prices there than on international routes
`priority`	No	Priority boarding
`cabin_bag`	No	A large cabin bag for the overhead locker
`hold_bags`	No	Checked bags per person (default 1); the 2nd bag often costs more
`group_bags`	No	Checked bags shared by the whole party, fewer than the people (e.g. 1 bag between 2): priced as that many 1st bags; needs checked_bag_kg
`passengers`	No	People aged 2+ (default 1)
`checked_bag_kg`	No	Checked bag(s) per person of this weight allowance

Output Schema

Name	Required	Description	Default
`note`	No
`page`	No
`error`	No
`lines`	No
`airline`	No
`true_cost`	No
`extras_total`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

addedInput schema / properties / group_bags

Added value: +{
+  "description": "Checked bags shared by the whole party, fewer than the people (e.g. 1 bag between 2): priced as that many 1st bags; needs checked_bag_kg",
+  "maximum": 8,
+  "minimum": 1,
+  "type": "integer"
+}

Changed1 schema field changedOct 29, 2026

addedInput schema / properties / domestic

Added value: +{
+  "description": "true for a flight within the US: US airlines charge different bag prices there than on international routes",
+  "type": "boolean"
+}

Changed3 schema fields changedOct 29, 2026

addedInput schema / properties / currency / description

Added value: +"Currency of the answer: EUR (default) or GBP, as the airline publishes it"

addedInput schema / properties / priority / description
```
Added value: +"Priority boarding"
```

addedInput schema / properties / trip / description

Added value: +"one_way (default) or return: return counts each extra on both flights"

Changed2 schema fields changedOct 21, 2026

changedInput schema / properties / checked_bag_kg / description

Previous value: -"One checked bag per person of this weight allowance"New value: +"Checked bag(s) per person of this weight allowance"

addedInput schema / properties / hold_bags

Added value: +{
+  "description": "Checked bags per person (default 1); the 2nd bag often costs more",
+  "maximum": 3,
+  "minimum": 1,
+  "type": "integer"
+}

First observedOct 20, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive and closed-world behavior, and the description is consistent with all of them. It adds real context beyond the annotations: prices come 'as the airline publishes', results are ranges, airport-purchase surcharges and unchosen fees (admin, card %) are surfaced, and unpublished extras are flagged rather than priced. It does not mention limits such as missing airlines or unsupported currencies.

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?

The mode distinction (fare given vs omitted) is front-loaded in the first two sentences, which is the highest-value information. The trailing sentence about airport surcharges and unpublished fees is dense but slightly run-on, packing four separate output concepts into one clause chain.

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?

For a 13-parameter read-only estimator with an output schema and full annotation coverage, the description supplies the one thing structured fields cannot: how fare-present and fare-absent modes differ and what the extras represent. Nothing critical is missing, though a note on which airlines are covered (presumably list_airlines) would round it out.

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, including the hold_bags vs group_bags distinction and the domestic bag-pricing note. The description reinforces the party-level framing of `fare` and the 'for their party and trip' scope, but largely restates what the schema already carries, so the baseline of 3 applies.

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 computation over a specific resource ('the true cost of a flight on one airline') and immediately decomposes it into fare + extras, so an agent knows exactly what is produced. It does not name or contrast the sibling tools (airline_fees, trip_at_airport), leaving the differentiation to be inferred from names alone.

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 gives a clear conditional rule: pass `fare` when you already have a party-level total from a flight-search tool or the person, omit it to get extras alone. That is genuine use-case guidance, but there is no when-not clause and no explicit pointer to airline_fees or trip_at_airport as alternatives.

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

All Airfare Brain 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.