True cost of flight extras (bags, seats, fees) on 29 airlines in Europe and North America, sourced.
Scored across 5 tools
airline_fees returns the published fee table for an airline, while true_cost computes a personalized total for a party and trip; the descriptions make this boundary clear. trip_at_airport overlaps with true_cost but is distinguished by adding car hire. The only mild confusion is get_capabilities versus list_airlines, which both serve discovery.
The set mixes verb_noun names (get_capabilities, list_airlines) with bare noun phrases (airline_fees, true_cost, trip_at_airport). All names are descriptive and readable, but there is no single predictable pattern.
Five tools is well-scoped for a fee-data server: discovery, per-airline lookup, cost calculation, a bundled trip answer, and capability documentation. No obvious redundancy or padding.
The surface covers discovery, raw fee data, personalized cost calculation, and a combined trip-plus-car-hire answer, which is solid lifecycle coverage for a research (non-booking) tool. A cross-airline comparison or route/airport-based fee search is a minor gap that agents could work around via list_airlines plus repeated calls.
One airline's published extra fees (bags, seats, priority, check-in, changes, payment), each with the price range, when bought (at booking / later / airport), how it is charged, its source URL and the date checked. Optionally filter by category.
| Name | Required | Description | Default |
|---|---|---|---|
| airline | Yes | Name or IATA code, e.g. 'Ryanair', 'FR', 'easyJet', 'W6' | |
| category | No | Only fees of this kind; omit for every fee the airline publishes | |
| currency | No | Currency of the answer: EUR (default) or GBP, as the airline publishes it |
| Name | Required | Description |
|---|---|---|
| fees | No | |
| note | No | |
| page | No | |
| error | No | |
| airline | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile needs no restating. The description adds genuine value beyond that: each fee carries a price range, purchase timing (at booking / later / airport), charging method, source URL and date checked — provenance detail an agent needs to judge data freshness and trustworthiness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the resource and then the returned fields, followed by a short filter note. Nearly every clause earns its place; only the trailing filter remark is mildly redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return structure need not be spelled out, and the description still summarizes the key fields anyway. Combined with fully documented parameters and clear annotations, an agent has enough to call it correctly; the missing piece is cross-tool routing against true_cost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both enum parameters are documented in the schema, so baseline is 3. The description's 'Optionally filter by category' merely restates what the category param already says; it adds nothing about currency handling or airline-name vs IATA-code acceptance that the schema doesn't already give.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (one airline's published extra fees) and enumerates the fee families covered (bags, seats, priority, check-in, changes, payment). An agent can tell it retrieves per-airline fee reference data, distinct from siblings like true_cost, but the description never names or contrasts those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage signal is 'Optionally filter by category', which covers filtering but not when to prefer this over true_cost or list_airlines. No preconditions, no exclusions, no alternative routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What Airfare Brain covers: airlines, how fees are researched and dated, what it does NOT do (no live fares, no booking), and what car hire at the destination airport typically costs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | No | |
| error | No | |
| method | No | |
| airlines | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds meaningful behavioral context by disclosing the tool's scope, explicit exclusions (no live fares, no booking), and inclusion of typical car hire costs, which helps the agent understand what information will be returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that lists the covered domains and the important exclusions without any filler. Every clause contributes directly to scope understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter informational tool with an output schema and full annotations, the description covers the essential aspects an agent needs: what is covered, what is explicitly not covered, and related cost information. The output schema handles return details, though the description could be slightly stronger by explicitly stating that it returns a structured capabilities summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description correctly adds no parameter guidance because none is needed, and it uses the space to explain the tool's informational content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description makes clear that this tool describes Airfare Brain's coverage: airlines, fee research, limitations, and destination car hire costs. It effectively distinguishes scope from siblings like airline_fees and trip_at_airport, though it relies on the title for the explicit 'get' verb rather than stating an action in the description itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists what the tool does NOT do (no live fares, no booking) and defines coverage boundaries, implying it should be used as a reference before other tools. However, it does not explicitly say when to call it versus alternatives or that it should be called first, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every airline with a fee table: name, IATA code, the date its fees were checked, and its page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | No | |
| error | No | |
| airlines | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the scoping detail that only airlines with a fee table are returned and what fields come back, which is modest but real added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the scoping clause ('with a fee table') leads and the returned fields follow compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list tool with a full output schema and complete annotation coverage, the description supplies everything needed to invoke it correctly. The only shortfall is the absence of any routing guidance against the sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify about inputs, and it does not confuse the reader with phantom arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('List') plus resource ('every airline') and it enumerates the returned fields (name, IATA code, date fees checked, page). It is clearly distinguishable in intent from siblings like airline_fees or true_cost, but it never names or contrasts those siblings directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to call this versus airline_fees, true_cost, or get_capabilities. The only implied usage comes from the word 'List', which leaves the agent to infer the routing decision on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The whole trip into one airport in one answer: the flight's extras on an airline (bags, seats, fees, as true_cost) AND what car hire there really costs (Car Rental Brain's measured median per day, car only, dated). Use for 'flying to Faro with Ryanair, bags and a hire car: what will it cost?'. Car only: deposits, second-driver fees and desk cover are not included; the answer links to the airport's full car-hire report.
| Name | Required | Description | Default |
|---|---|---|---|
| fare | No | Total fare for the whole party, if known | |
| seat | No | Paid seat choice: none (random seat), standard, or extra (legroom / front) | |
| trip | No | one_way (default) or return: return counts each extra on both flights | |
| airline | No | Airline name or IATA code (optional; without it you get car hire only) | |
| airport | Yes | IATA code or name of the airport you fly INTO, e.g. 'FAO', 'Faro', 'Malaga' | |
| infants | No | Under-2s on a lap (default 0) | |
| car_days | No | Days of car hire (default 7) | |
| 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 (the small under-seat bag is free) | |
| 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, e.g. 20 or 23; omit for none |
| Name | Required | Description |
|---|---|---|
| note | No | |
| error | No | |
| flight | No | |
| airport | No | |
| car_hire | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description correctly spends its words on scope limits instead: car hire is 'car only' and excludes deposits, second-driver fees and desk cover, and the answer links to the full report. That is meaningful disclosure beyond the annotations, though it does not say how the median is dated or sampled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core promise is front-loaded in the first sentence, followed by a use-case example and then the car-only caveat. It is dense and mostly earns its length, though the embedded example quote is longer than needed to convey the intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters, an output schema, and rich annotations, the description supplies what structured fields cannot: the composite nature of the answer, the optional-airline branch, and the car-hire exclusions. Only the dating/measurement basis of the car-hire figure is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including enums and defaults is already documented. The description adds only one semantic point (airline is optional and omitting it yields car hire only); the bag/seat/passenger semantics are left entirely to the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific composite output: airline flight extras (bags, seats, fees as true_cost) plus measured car-hire median per day at a given airport. This is clearly distinguishable from siblings like airline_fees or true_cost, which appear to cover only one half of the calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete triggering example ('flying to Faro with Ryanair, bags and a hire car: what will it cost?') and states the condition that drops the flight half ('without it you get car hire only'). It never names the sibling tools to use instead for flight-only or cost-only questions, so routing guidance is clear but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| Name | Required | Description |
|---|---|---|
| note | No | |
| page | No | |
| error | No | |
| lines | No | |
| airline | No | |
| true_cost | No | |
| extras_total | No |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
trip_at_airport1 field changedInput schema / properties / group_bagsAdded 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"
+}true_cost1 field changedInput schema / properties / group_bagsAdded 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"
+}trip_at_airport1 field changedInput schema / properties / domesticAdded value: +{
+ "description": "true for a flight within the US: US airlines charge different bag prices there than on international routes",
+ "type": "boolean"
+}true_cost1 field changedInput schema / properties / domesticAdded value: +{
+ "description": "true for a flight within the US: US airlines charge different bag prices there than on international routes",
+ "type": "boolean"
+}airline_fees2 fields changedInput schema / properties / category / descriptionAdded value: +"Only fees of this kind; omit for every fee the airline publishes"Input schema / properties / currency / descriptionAdded value: +"Currency of the answer: EUR (default) or GBP, as the airline publishes it"trip_at_airport9 fields changedInput schema / properties / cabin_bag / descriptionAdded value: +"A large cabin bag for the overhead locker (the small under-seat bag is free)"Input schema / properties / checked_bag_kg / descriptionAdded value: +"Checked bag(s) per person of this weight allowance, e.g. 20 or 23; omit for none"Input schema / properties / currency / descriptionAdded value: +"Currency of the answer: EUR (default) or GBP, as the airline publishes it"Input schema / properties / hold_bags / descriptionAdded value: +"Checked bags per person (default 1); the 2nd bag often costs more"Input schema / properties / infants / descriptionAdded value: +"Under-2s on a lap (default 0)"Input schema / properties / passengers / descriptionAdded value: +"People aged 2+ (default 1)"Input schema / properties / priority / descriptionAdded value: +"Priority boarding"Input schema / properties / seat / descriptionAdded value: +"Paid seat choice: none (random seat), standard, or extra (legroom / front)"Input schema / properties / trip / descriptionAdded value: +"one_way (default) or return: return counts each extra on both flights"true_cost3 fields changedInput schema / properties / currency / descriptionAdded value: +"Currency of the answer: EUR (default) or GBP, as the airline publishes it"Input schema / properties / priority / descriptionAdded value: +"Priority boarding"Input schema / properties / trip / descriptionAdded value: +"one_way (default) or return: return counts each extra on both flights"trip_at_airporttrue_cost2 fields changedInput schema / properties / checked_bag_kg / descriptionPrevious value: -"One checked bag per person of this weight allowance"New value: +"Checked bag(s) per person of this weight allowance"Input schema / properties / hold_bagsAdded value: +{
+ "description": "Checked bags per person (default 1); the 2nd bag often costs more",
+ "maximum": 3,
+ "minimum": 1,
+ "type": "integer"
+}airline_feesget_capabilitieslist_airlinestrue_costIs this flight price good? Buy-or-wait verdict from 90 days of real observed fares per route
Airline seat quality scores (1-10) with notes. 61+ configs across 10 US airlines.
Real cost of car hire at 120+ airports: second driver, cover, deposits, debit cards, desk hours.
Flight search, airfare analytics, flexible destinations
Add one secure layer between your agents and this server.
