cwsi.net Fare Classes & Mileage Calculators

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

With annotations already declaring readOnlyHint, idempotentHint, destructiveHint false, and openWorldHint false, the description adds substantial behavioral context: the tier-mile formula, award-mile multipliers by status, Gold extras requiring toCountry, the 12-month progress logic, the note-only status of future rules, and the unofficial cwsi.net data source. It also discloses that unlisted classes or routes earn nothing and says so, which is useful transparency for a calculator. It does not contradict the annotations.

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 front-loaded with the core purpose, but it quickly becomes a dense, comma-heavy paragraph that is difficult to parse. Much of the detail is relevant for this complex calculator, yet the lack of paragraph breaks or clear grouping makes it less concise than it could be. It is appropriately sized for the domain but structurally weak.

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?

Given the high complexity, the 10-parameter schema, the 100% schema description coverage, and the presence of an output schema, the description provides an unusually complete picture. It covers calculation rules, fare family and booking class semantics, award-mile multipliers, Gold extras, progress tracking, partner-program crediting, and data provenance. An agent has enough context to call the tool correctly without needing return-value explanations that the output schema already supplies.

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 each parameter in detail, making 3 the baseline. The description adds meaningful parameter context beyond the schema: it explains that Gold extras need toCountry, that segs entries are one-way flights in order with required from/to IATA codes, that creditTo uses creditFlights with great-circle miles, and that the tool takes no price. These relationships and constraints go beyond raw field descriptions.

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 opens with a specific verb and resource: it calculates Aegean Airlines Miles+Bonus tier miles and award miles for Aegean and Olympic Air flights. It immediately distinguishes the scope from sibling airline calculators by naming the airline programs and the underlying route table, so an agent can identify the correct tool without opening the schema.

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 states the scope of applicability (Aegean/Olympic flights, route-table-based earning, fare family and booking class constraints) and notes that unlisted classes or routes earn nothing. However, it never explicitly says when to choose this tool over the many sibling airline calculators, nor does it name alternatives for non-Aegean flights. The usage is implied by the airline-specific name and scope, but the guidance remains implicit.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantive behavior: rounding down, no minimum, no elite bonus, refusal-with-message for non-Argentina flights or unlisted letters, tier thresholds, and provenance ('cwsi.net's calculator', 'Unofficial'). That is well beyond what the annotations convey.

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?

Front-loads the core formula before branching into zones, refusal rules, tiers and input format. It is dense and somewhat run-on (mixing earning rule, status progression and provenance in one paragraph), but every sentence carries information relevant to correct invocation.

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 an output schema, 100% schema coverage and full annotations, the description only needs to carry the domain model, which it does (earning rule, zones, rounding, tier progression, refusal behavior). It omits mention of the Flying Blue creditTo/creditClass/creditStatus path, though the schema documents those fully.

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%, so 3 is the floor, but the description supplies the zone definitions (Domestic = both airports in Argentina; the specific Regional and International country lists) that are not in the schema and are required to pick the correct fare percentage. It also clarifies segs ordering and that no price is taken, adding real meaning on top of the schema.

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 verb+resource ('Aerolineas Argentinas Aerolineas Plus miles for Aerolineas Argentinas flights') and immediately gives the earning rule (distance x a fare-letter/zone percentage). The airline is named explicitly, so it is trivially distinguishable from the dozens of sibling airline calculators.

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?

Gives clear context on when the tool applies (flights touching Argentina, listed fare letters, no price) and routes the agent to the companion tool by saying the segs miles come from 'calculate_flight_distance'. It also notes the refusal condition for out-of-scope flights, but does not explicitly contrast itself against other calculator siblings.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is low. The description adds meaningful behavioral context beyond them: it discloses that the tool is unofficial, that it uses cwsi.net's calculator and published rules, and flags a nontrivial judgment call (the per-level 'additional accrual' is deliberately not added). No return-format detail is needed because an output schema exists.

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?

Front-loads the core purpose and earning formula before edge cases, and every sentence (rounding, Basic Economy exception, additional-accrual decision, progress thresholds) carries real information. It is dense as a single block and could be split, but there is no filler.

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?

Complete for a computation tool with a rich 8-param schema and an output schema: it explains the earning formula, the qualifying-points distinction, the escalation thresholds, currency handling, and the partner-crediting alternative, so an agent has everything needed to call it correctly. Return values are covered by the output schema, so omitting them is appropriate.

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 baseline is 3, but the description adds tie-in semantics: it clarifies that price drives the 8-per-dollar formula, that fam only matters via the Basic Economy exception, and that status/qp affect only progress, not earning. This meaningfully reinforces the parameter roles on top of an already complete schema.

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 verb+resource: calculates Aeromexico Rewards points and qualifying points for an Aeromexico-operated flight, with the exact earning rule (8 points per USD of base fare, rounded down). The airline name distinguishes it from the ~50 sibling calculators, and it names the one alternate path (creditTo partner programs).

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?

Gives clear operating context: level does not change earning, status/qp are used only for progress, Basic Economy earns points but no qualifying points, and price is required unless creditTo is given. It points to calculate_flight_distance as the source of the miles it needs. It does not explicitly state when to prefer this tool over a sibling airline calculator, but the airline scoping makes that self-evident.

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

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

Annotations already declare a safe, idempotent, closed-world read, so the bar is lower; the description still adds real substance by disclosing that the result is an unofficial estimate derived from cwsi.net's calculator plus published rules, and by laying out the exact points and SQC formulas. That is meaningful context beyond the annotation block.

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?

Front-loads the purpose and formulas, then handles both modes compactly in a few sentences with no repetition. The trailing one-word 'Unofficial.' is slightly abrupt but carries a real caveat.

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 an 8-parameter tool with two distinct modes and an output schema (which relieves it of explaining return values), the description covers the modes, the required inputs, and the calculation basis adequately. Minor gaps remain around what exactly the estimate returns for the creditTo path, but nothing blocking.

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 fare brands, status multipliers, and the creditTo pathway in detail, making 3 the baseline. The description reinforces the CAD-only requirement and the price-vs-creditTo exclusivity but adds little the schema does not already state.

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 verb and resource ('Estimate the Aeroplan points and SQC'), names the exact scope (Air Canada-ticketed 014 fare), and covers both the own-program and partner-credit modes. An agent can distinguish it from the ~50 sibling airline calculators by the carrier named in the title and first sentence.

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?

Gives usable routing conditions: use it for Air Canada-ticketed fares, supply the price in CAD, and 'leave creditTo out for the airline's own program' versus giving creditClass/creditFlights to credit to a partner. It stops short of naming the sibling to use instead (e.g. calculate_united_miles) when crediting elsewhere, so it is clear context without explicit alternatives.

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

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

Annotations only declare this is a safe, idempotent, non-open-world read. The description goes well beyond that: it discloses the tool is "Unofficial," uses cwsi.net's calculator plus published rules, takes no price, shows the elite bonus as a note only, and does not add the flight to progress. These are substantive behavioral disclosures.

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?

It is front-loaded with purpose and then flows into rules and usage, with each sentence carrying calculation or input meaning. It is dense and a single unstructured block that repeats some schema content (e.g., O/I/X/N earn nothing), which keeps it from a 5.

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 10-parameter calculator with an output schema and safety annotations, the description supplies the missing methodology, edge cases (zero-earning classes, dual rates), and progress semantics. Nothing an agent needs to invoke it correctly is absent.

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 baseline is 3; however the description adds computation semantics the schema lacks, such as the mileage formula (km = IATA distance x 1.609344 x class %), minimums per cabin, dual-rate mainland/regional rule, and the dynamic relationship between cls, creditClass, segs and creditFlights.

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 first sentence states a specific verb and resource: PhoenixMiles mileage (in km) and qualifying segments for Air China flights. It is unambiguously distinguishable from its many sibling airline calculators by naming the Air China program and noting it is unofficial.

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 concrete input guidance ("Give segs: one entry per one-way flight, in order") and points to the sibling calculate_flight_distance for the miles value, which is a genuine routing hint. It lacks explicit when-not-to-use or a direct contrast against the other airline calculators, but context is clear.

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

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

Annotations already confirm a safe read-only, idempotent, non-destructive operation. The description adds substantial behavioral context: the exact calculation rules, rounding, that Level Miles are not published and therefore not calculated, the data source (cwsi.net), the unofficial status, and a currency warning. This goes well beyond what structured fields provide.

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 first sentence is long and dense, and the inclusion of Level Miles thresholds (18,000/32,000/60,000 or 14/26/50 flights) is tangential to calculating redeemable miles. Information is front-loaded, but the description carries unnecessary detail that dilutes focus.

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 an 8-parameter tool with two distinct operating modes (own program vs partner crediting), the main description only covers the Air Europa Suma Miles mode and entirely omits the creditTo, creditClass, creditStatus, and creditFlights functionality. Although the schema documents those parameters, the description leaves an agent unaware of the tool's full capability.

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 all eight parameters thoroughly. The description restates some rules (5 Miles per EUR, route/cabin bonuses, level bonuses) but adds no per-parameter meaning beyond the schema, particularly for the four creditTo-related parameters it ignores entirely.

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 the specific airline (Air Europa) and program (Suma Miles), clearly distinguishing it from the many sibling airline mileage calculators. An agent can tell immediately what this tool computes.

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 airline name implies the tool is for Air Europa tickets, but there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives among the sibling calculators. The description also fails to note when to use the partner credit mode versus the default mode.

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

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

Annotations already cover the safety profile (readOnly/idempotent/non-destructive), yet the description adds substantial operational context: rounding down, the unstated FX conversion behavior, the direct-booking bonus that adds Maharaja Points but not Tier Points, tier thresholds (15,000/30,000/45,000 over 365 days), and the 'unofficial, uses cwsi.net' provenance caveat.

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 formula and the INR instruction are front-loaded, and every clause carries rule content rather than filler. It is a dense single paragraph, however, and the 'give the INR amount, not US dollars' instruction is effectively repeated at the end, which is mild redundancy.

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 9-parameter calculator with an output schema (so return values need not be explained), the description covers the carrier/tier/direct math, the creditTo partner branch, and the currency constraint, plus provenance. Nothing needed to call it correctly is missing.

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%, so the baseline is 3, but the description goes beyond field definitions by explaining how parameters interact: fare/100 x tier multiplier, +2 per INR 100 only when direct=YES on Air India, carrier AI counting base fare plus YQ versus IX counting base fare only. This formula-level context is not restated from the schema.

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?

Names the specific output (Maharaja Points and Tier Points) for a specific carrier set (Air India / Air India Express carrier IX), with the exact input basis (fare in INR). Against ~50 sibling calculators that differ only by airline, the carrier-specific scope makes it unmistakable which one to pick.

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?

Gives concrete routing rules: give the price in INR rather than USD because Air India converts foreign currency itself, and 'leave creditTo out for the airline's own program' while describing the partner-program path. It also points to calculate_flight_distance as the source of creditFlights miles. It stops short of naming an explicit alternative tool for partner crediting, so not a full 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is low, and the description adds substantial domain behavior: zero-earn classes, F earning only Status Points, decimals, unlisted pairs being skipped, tier irrelevance, and the 'uses cwsi.net, unofficial' caveat. It does not cover error behavior or output interpretation, but for a read-only calculator this is well beyond the structured fields.

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 earn logic, exclusions and segs format are front-loaded and information-dense. It is a single semicolon-chained paragraph of roughly 180 words with some repetition of the fare list and airline name, so a couple of sentences could be trimmed.

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 10-parameter tool with two distinct modes, the description covers only the airline's own program and never mentions creditTo/creditClass/creditStatus/creditFlights or that an alternative crediting path exists. Output schema and schema descriptions compensate for return values and per-param detail, but the mode split is a real omission.

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%, so baseline is 3, but the description adds real meaning: it expands the fare enum names (Seat, Seat+Bag, Flexi Change, Flexi Refund, The Works), explains 'sp' as Status Points so far, describes segs as one entry per one-way flight with required from/to, and notes distance/countries don't matter. It goes beyond the enum labels rather than restating them.

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 verb and resource ('Air New Zealand Koru Airpoints and Status Points for Air New Zealand flights') and immediately scopes it: fixed earn per flight from ANZ's own tables, keyed by airport pair, booking class and fare. It also explicitly distinguishes itself from the ~50 sibling calculators by declaring partner-airline flights and unlisted pairs are not counted.

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?

Gives domain conditions (N/I/R/X earn nothing, F earns Status Points only, tier does not change earning) and notes partner-airline flights are not calculated. But there is no routing to alternatives — e.g. calculate_flight_distance is only named in the schema, not the description — and the entire creditTo/partner-crediting mode, which is a major alternative path this tool supports, is never mentioned in the description.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description usefully adds that it is an 'Estimate', that it is 'Unofficial', and that results are derived from cwsi.net's calculator plus the airline's published rules — signalling approximation and possible staleness, which the annotations do not convey.

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?

Two compact sentences, front-loaded with the primary estimate action and closing with the sourcing/provenance caveat. No padding or redundancy, though it is arguably too terse for a 14-parameter tool.

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 values need not be explained. However, for a tool with 14 interacting parameters and a major 2026/2027 earning-method regime change, the description gives no orientation to those complexities, leaving the agent fully dependent on the schema to understand the two distinct calculation regimes.

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% and each of the 14 parameters carries a detailed description (enum semantics, defaults, applicability notes), so the schema does the heavy lifting. The description adds no parameter-level meaning beyond that, making the baseline of 3 appropriate.

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 verb ('Estimate') and resource ('what an Alaska Airlines ticket earns — miles or points, and status credit'), which is immediately distinguishable from the per-airline siblings by the named carrier. It stops short of explicitly contrasting itself with adjacent tools like calculate_flight_distance or the partner calculators, but the core purpose is unambiguous.

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?

There is no when-to-use or when-not guidance, no prerequisites, and no mention of alternatives. This matters because the schema exposes a creditTo path that overlaps with sibling tools (calculate_american_miles, calculate_british_airways_avios), and the description never tells the agent when to prefer one over the other.

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

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

Annotations already declare readOnly, idempotent and non-destructive behavior, so the safety profile is covered. The description still adds real value beyond them: it discloses the estimation methodology (cwsi.net's calculator plus the airline's published rules) and an 'Unofficial' disclaimer the agent would otherwise not know.

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 whose parenthetical adds scope rather than padding, capped by a two-word disclaimer. No sentence is wasted.

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 an output schema present, return values need no explanation, and all parameters plus the safety profile are covered by structured fields. The only missing piece is any hint about input units beyond the schema or what 'status credit where it applies' means in practice, which is minor.

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% — both 'price' (qualified spend ex-taxes/fees) and 'card' (the AV enum worth 3 points per $1) are fully documented in the schema. The description adds no parameter-level detail beyond that, so the 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?

States a specific verb (Estimate) plus the exact resource (an Allegiant Air ticket's earnings), and even names the reward currencies involved (miles/points, status credit). This distinguishes it cleanly from the dozens of sibling airline calculators, which differ only by carrier.

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?

Usage is only implied by the airline name — an agent can infer it applies to Allegiant earnings, but the description gives no explicit when-to-use guidance and never mentions relevant siblings such as calculate_flight_distance or compare_fare_classes. Adequate but with a clear routing gap.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds two genuinely useful facts beyond that: results are estimates, not exact, and they come from cwsi.net's calculator plus published airline rules ("Unofficial"). It says nothing about determinism or edge cases, so this is solid but not rich.

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 sentence with no filler, front-loading the purpose and appending the important "Unofficial" caveat. Minor awkwardness in phrasing ("what a American Airlines ticket earns") but nothing wasteful.

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 an output schema present, return values need no explanation, and 100% parameter coverage plus read-only annotations mean the structured fields cover most needs. The remaining gap is cross-tool routing (creditTo to Alaska vs. calculate_alaska_miles, and the dependency on calculate_flight_distance for creditFlights.miles, which is only mentioned in the schema).

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% and the enum values, card multipliers, status bonuses and creditTo mechanics are all documented inline. The description adds no parameter-level meaning; it only hints that outputs may be miles, points or status credit. Baseline 3 is appropriate when the schema carries the burden.

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 verb and resource: "Estimate what a American Airlines ticket earns (miles or points, and status credit where it applies)". An agent can tell this is the AAdvantage earning calculator. It does not distinguish itself from siblings, though the airline-specific name plus the ~50 parallel calculators makes that differentiation largely self-evident.

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?

Scope is implied — it covers American Airlines tickets and status credit "where it applies" — but there is no explicit when-to-use/when-not statement. Notably, the tool supports crediting to Alaska (creditTo) which overlaps with the sibling calculate_alaska_miles, and the description never routes the agent between the two; that guidance lives only in the schema.

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

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

Annotations already cover the safety profile (readOnly/idempotent/non-destructive/closed-world), but the description adds genuinely new behavioral context: the underlying data source ('cwsi.net's calculator and the airline's published rules'), an authoritative caveat ('Unofficial'), and an input-coverage statement ('Takes no price'). It does not discuss precision, rounding, or rule-version staleness, so it is not exhaustive.

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 purpose is front-loaded in sentence one, and nothing is pure filler, but the rest is a single dense paragraph that interleaves the earning-rate table, the Premium Points formula, input format instructions, and sourcing caveats. Substantial portions (the class-rate enumeration, the segs field guidance) restate what the schema already carries, so the text is longer than it needs to be.

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 an 11-parameter tool with a nested segs array and an output schema, the description covers the core path end to end: what it computes, the formula, the required per-segment shape, the dependency on calculate_flight_distance, and the data source/disclaimer. Return values are covered by the output schema, so their absence here is not a gap.

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 baseline is 3; the description earns above that by explaining how the parameters interact (miles = distance x booking-class rate; Premium Points adds route ratio and 400 boarding points) and by adding an actionable rule not spelled out in the schema ('set from or to to VVO for Vladivostok, which shares RU with the rest of Russia'). It still says nothing about the creditTo/creditClass/creditStatus/creditFlights family, leaving a quarter of the parameters purely schema-defined.

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 verb and resource ('Estimate the ANA Mileage Club miles and Premium Points') and bounds the scope to 'flights operated by the ANA Group', which an agent can distinguish at a glance from the ~50 sibling airline calculators. It goes further by naming the exact formulas used, so the agent knows what output to expect.

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?

Gives clear input guidance ('Give segs: one entry per one-way flight...') and routes the agent to the sibling that produces the needed miles value ('calculate_flight_distance gives them'), plus the unusual VVO-for-Vladivostok instruction. It never states an explicit when-not or names a competing tool, so it stops short of a 5.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuine extra context by disclosing that results are estimates, that it relies on cwsi.net's calculator plus published rules, and that it is "Unofficial" – all useful for calibrating trust in the output.

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 compact sentence leads with the core purpose and tucks the provenance and "Unofficial" caveat into a short trailing clause. Nothing is wasted, though the parenthetical is slightly dense.

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 an output schema present, the description need not explain return values, and annotations handle the safety profile. The description covers purpose, estimation caveat, provenance, and scope, which is sufficient for a low-risk, single-required-parameter calculator.

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% and each enum value (card, fare, status) is already fully documented in the schema. The description adds no fare/status/card semantics beyond what the schema provides, 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 pairs a specific verb ("Estimate") with a specific resource ("what a Breeze Airways ticket earns") and even names the sub-outputs (miles or points, status credit). The Breeze Airways name naturally separates it from the many sibling airline calculators, though it never explicitly frames itself as the Breeze-specific alternative.

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?

Usage is implied by the airline scope and the earnings context, but there is no explicit when-to-use guidance, no prerequisites, and no pointer to a sibling or alternative. Nothing tells the agent what a caller must already know (fare/bundle data) before invoking it.

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

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

Annotations already declare readOnly, idempotent, and closed-world, so safety is covered. The description adds two genuinely non-structured facts: results are derived from cwsi.net plus published airline rules, and the output is 'Unofficial'. It does not disclose the two distinct calculation modes (own programme vs creditTo partner) or that most fare-type fields are ignored depending on cabin.

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?

Two short sentences with the core scope front-loaded and the practical currency constraint immediately after. No filler, though the 'miles or points' parenthetical is slightly redundant with the airline context.

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 an output schema present and full schema coverage, the description needn't explain return values or fields, and it doesn't. However, for a 19-parameter tool with mutually exclusive cabin/fare-type combinations and a whole alternative creditTo pathway, the description says nothing about the two modes of use, leaving the agent to reconstruct them from the schema.

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 one of the 19 parameters, including the creditTo/creditClass/creditFlights trio, is already documented in detail. The description only restates the GBP currency requirement, which the price schema field also states. Baseline 3 is appropriate when the schema does all the parameter work.

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 verb and resource: 'Estimate what a British Airways ticket earns (miles or points, and status credit)'. The airline name plus the miles/points/status-credit scope separates it from the many sibling calculators without needing to name them. It does not explicitly contrast with near-neighbours like calculate_iberia_avios or calculate_qantas_points, so it stops short of a 5.

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?

'Give the price in GBP, not US dollars' is the only usage constraint, and it is really a parameter rule. Nothing says when to use this versus compare_fare_classes, get_fare_classes, or the creditTo partner path, and the 'Unofficial' caveat is stated without saying how much to trust the result. Usage is implied by the tool name rather than explained.

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

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

Annotations already declare this a read-only, idempotent, non-destructive calculation. The description adds a meaningful transparency note beyond that: 'Unofficial,' flagging that the numbers come from a third-party calculator and airline rules rather than a guaranteed source. It adds no return format or rate-limit detail, but the output schema carries the result shape.

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?

Front-loaded with the purpose, then the prerequisite, then the one non-obvious conditional rule, then a caveat. Every sentence carries weight, though the t2 guidance partially duplicates the schema enum description.

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 an 11-parameter tool with an output schema and full schema coverage, the description supplies what structured fields don't: the cross-tool dependency on calculate_flight_distance, the special t2 case, and the 'Unofficial' caveat. Partner-credit mechanics live in the schema, so nothing critical is missing.

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 t2 country list and its 'ignored otherwise' behavior. The description restates the t2 rule with the distance threshold, which adds operational emphasis but little information beyond the schema itself; baseline 3 is appropriate.

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 verb and resource: 'Estimate what a Cathay Pacific flight earns (miles and status points) from its distance in miles, booking class and fare type.' It also names its inputs at a high level and the data source (cwsi.net's calculator plus published rules), clearly separating it from the other airline calculator siblings.

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?

Gives an explicit prerequisite ('Get the miles from calculate_flight_distance') and a concrete conditional rule for t2 (751–2,750 mile flights to/from JP, ID, LK, NP, BD, IN). It does not state when-not to use this tool versus a competing program's calculator, but the airline-specific name makes that largely self-evident.

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

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

Annotations already cover the safety profile (readOnly/idempotent/non-destructive/closed-world). Beyond them the description adds real behavioral detail: rounding to the nearest mile per flight with no minimum, that the 15/25/30% tier incentive is a note only, that Status Points per flight are not calculated, and that the source is cwsi.net plus published rules and is unofficial.

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 formula is front-loaded, which is good, but the body is a dense run-on of semicolon-joined clauses and it duplicates the class-percentage table that the schema already lists, which is wasted length.

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 complex 9-parameter tool this covers the earning rules, rounding, exclusions (no status points, no price) and source disclaimers well, and an output schema exists so return values need no explanation. The creditTo/partner-program branch is documented but terse relative to its complexity.

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 baseline is 3. The description restates the booking-class percentages already fully enumerated in cls's schema and re-explains the segs shape, adding little semantics beyond what the structured fields carry.

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 verb+resource ('China Airlines Dynasty Flyer miles for China Airlines flights') and scopes it to one airline, cleanly distinguishing it from the many sibling airline calculators. The earning formula is given up front, so an agent immediately knows what is being computed.

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 clarifies the scope (China Airlines flights, no price taken) and routes to alternatives via 'calculate_flight_distance gives them' for segment miles and via creditTo for crediting to partner programs instead of Dynasty Flyer. It gives clear context but stops short of explicit when-not/exclusion statements.

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

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

Annotations already cover the read-only, idempotent, non-destructive, closed-world profile, and the description adds real context beyond them: the result is rounded down with no minimum, progress is driven by yearly spend plus qualifying segments/km, and the tool is explicitly "Unofficial" and built on cwsi.net's calculator. It omits return shape, but an output schema exists.

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 purpose and currency caveat are front-loaded, but the body is a single dense paragraph embedding two coefficient tables and level thresholds in prose, which is hard to parse. Information is relevant but not efficiently structured.

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 branching tool with eight parameters and an output schema (so return values need no explanation), the description covers both the own-program formula and the creditTo partner path, including the creditClass/creditFlights requirements. Minor gaps remain around the creditTo earning mechanics, but overall it is sufficient to call the tool correctly.

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% and the enum values already document the coefficient tables and channel/level meanings. The description largely restates those coefficients (1-star 0.264/0.24 up to Platinum 1.232/1.12) rather than adding new semantic detail, so the 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?

States a specific verb (calculate), resource (Eastern Miles), and precise scope (China Eastern, Shanghai Airlines or China United tickets, from fare plus YQ). Against a large sibling set of airline calculators, the airline scope and the exact earning formula make it unambiguous which tool applies.

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?

Explains when to use the own-program path versus the creditTo partner path ("leave creditTo out for the airline's own program"), and repeatedly instructs to supply CNY rather than another currency. No explicit when-not or pointer to sibling calculators, so it stops short of full routing guidance.

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

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

Annotations already declare this is a read-only, idempotent, non-destructive, closed-world computation, so the safety profile is covered. The description goes further by disclosing the provenance ('Uses cwsi.net's calculator and the airline's published rules') and the fact that it is 'Unofficial', plus the full deterministic earning logic, which is genuine added context. It does not cover failure modes or edge cases.

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?

Everything is compressed into a single front-loaded paragraph that opens with what is computed before moving to rules and inputs, and no sentence is pure filler. It is dense and unsegmented, and portions duplicate the schema, which keeps it short of a 5.

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 an 11-parameter tool with an output schema and annotations already present, the description covers the earning rules, the partner-credit path, the segs input shape and the qualifying-status thresholds, which is enough for correct invocation. Return values need not be described since an output schema exists.

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% and the schema itself is extremely detailed (fare-family percentages, enum labels, segs structure), so the baseline is 3. The description largely restates those same rules (fare family percentages, status bonuses, no-earn classes, qm/qs as year-to-date totals) rather than adding meaning beyond the schema, though 'Takes no price' and the segs ordering hint add marginal value.

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 verb and resource — computing ConnectMiles award miles, qualifying miles and qualifying segments for Copa flights — and spells out the earning model, so the agent knows exactly what is produced. It distinguishes itself from the ~50 sibling calculators mainly through the airline-specific rules it enumerates rather than an explicit contrast statement.

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 concrete invocation guidance: 'Give segs: one entry per one-way flight, in order, with its great-circle miles (calculate_flight_distance gives them)', names the prerequisite sibling tool, and states 'Takes no price' plus 'leave creditTo out for the airline's own program'. What is missing is an explicit when-not-to-use or a routing statement against other airlines' calculators, though that is largely implied by the airline name.

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

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

Beyond readOnly/idempotent annotations, the description discloses operational behavior: fixed mileage by class, no status bonus added, no price taken, route-refusal behavior, country-continent handling, and that it is unofficial and based on cwsi.net and published airline rules.

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 content is dense and front-loads purpose, but it is delivered as one very long paragraph rather than clearly structured guidance. Many details earn their place for a complex calculator, yet some repeat the schema and make the description heavier than necessary.

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?

Given the 12-parameter schema with 100% coverage, an output schema, and read-only annotations, the description supplies the remaining context an agent needs: route scope, class behavior, tier progress, country handling, alternatives and source limitations. It is complete enough to call the tool correctly.

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%, but the description adds meaningful semantics for key parameters such as cls, tc, segs, pts/qp/hp and status, including rules like Algeria, Egypt, Libya, Morocco and Tunisia counting as Europe. It does not cover creditTo/creditFlights, so it does not fully extend beyond the already rich schema.

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 calculation resource and scope: Miles & More miles, Points, Qualifying Points and HON Circle Points for flights operated by Croatia Airlines, by booking class. It distinguishes itself from siblings by specifying Croatia Airlines only and naming calculate_lufthansa_miles for Lufthansa Group bookings.

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 explicit when-to-use scope for Croatia Airlines flights and when-not conditions, including refusal for routes outside Europe, a domestic flight in another country, and zero earning for I, N, R and X. It names alternatives: calculate_lufthansa_miles for Lufthansa Group channels and calculate_flight_distance for great-circle miles.

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

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

Annotations already declare the safe, read-only, idempotent, closed-world profile, so the bar is lower. The description still adds genuine behavioral context beyond that: it discloses the underlying source (cwsi.net's calculator plus the airline's published rules) and flags the result as 'Unofficial', which is an accuracy/reliability caveat an agent should weigh. It does not discuss auth, rate limits, or determinism of results, so it is not a 5.

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 core verb and resource lead. The trailing list of outputs plus 'Unofficial' is efficient. It is well-sized, though slightly dense, which keeps it from a 5.

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 an output schema present, return values need no explanation, and full schema coverage means parameters are self-documenting. The description supplies the one thing structured fields cannot: what the number means and that it is unofficial. It omits guidance on the conditional price-vs-creditTo requirement, but the schema covers that, so the gap is minor.

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 all 8 parameters including enum meanings, the price/creditTo mutual exclusion, and the creditFlights structure. The description adds no parameter-level detail beyond what the schema provides. Baseline 3 applies when the schema does the heavy lifting.

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+resource: 'Estimate what a Delta Air Lines ticket earns (miles or points, and status credit)'. The airline name plus the Delta-specific tool name clearly separates it from the ~50 sibling calculators. It stops short of a 5 because it never names the adjacent alternatives (e.g. the partner-program calculators, calculate_flight_distance) that an agent might otherwise reach for.

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 gives no when-to-use, when-not-to-use, or alternative routing. Nothing tells the agent it should prefer calculate_flying_blue_miles / partner tools when crediting to a partner program, even though the tool accepts creditTo for exactly those programs. Usage has to be inferred entirely from the schema.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds behavior beyond them: it discloses the refusal path for unlisted cities, that it takes no price, that results come from cwsi.net's calculator, and that the tool is unofficial — useful context for trusting/validating output.

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 purpose is front-loaded in the first sentence, but the rest is a single undifferentiated block of reference rules (percentages, dates, rounding) that duplicates the schema rather than adding new information. For a 13-parameter tool the length is defensible, yet structure and non-redundancy suffer.

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 values need not be explained. Given the complexity (13 params, 8 enums, partner-program path via creditTo), the description covers eligibility, formulas, exceptions, refusal behavior and the unofficial disclaimer, leaving only the creditTo partner flow to the schema.

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 baseline is 3. The description's rule text (base 1,000–7,000, fare-brand percentages, tier bonuses, issued-date cutoffs) largely restates what the schema already documents for brand, issued, status, seat and stock, so the marginal semantic gain over structured fields is limited.

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 opening sentence names the specific resource (Etihad Guest Miles and Tier Miles) and the exact scope (Etihad-marketed and operated flights on a ticket starting 607/291/169, stock EY), which cleanly separates it from the dozens of other airline calculators in the sibling list. An agent knows immediately this is the Etihad earning calculator, not a generic distance or fare-class tool.

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 real applicability conditions: rates by fare brand apply only to Etihad tickets, other tickets (stock OT) 'are not worked out' and only return a table, promo seats (seat P) behave differently, and 'A city not on Etihad's list is refused.' It does not explicitly route the agent to calculate_flight_distance or compare_fare_classes, but the when-it-applies/when-it-does-not context is unusually strong.

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

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

The annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond them: it takes no price, is driven by cwsi.net's calculator plus the airline's published rules, and is explicitly unofficial, which tells the agent about accuracy caveats and the absence of fare input.

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?

Purpose is front-loaded in the first sentence, but the middle is a dense formula block that duplicates the cls enum's percentage list, and the segs/IATA-labeling detail reappears in the schema's seg descriptions. Earns most of its space, yet repeats structured data.

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 10-parameter tool with an output schema (so return values need not be described), it covers the earning math, tier bonus, partner-program crediting and progress inputs. Only the routing among sibling airline calculators is left unaddressed.

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 the cls enum already spells out every booking-class percentage, so much of the description's formula and sm/fl explanation restates the schema. It adds some value by tying segs/creditFlights together (defaulting creditFlights to segs), but the baseline of 3 is appropriate.

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?

Names a specific verb and resource: computes EVA Air Infinity MileageLands Award Miles, Status Miles and qualifying sectors. The airline and program identity are explicit, so an agent can separate it from the dozens of sibling calculate_*_miles tools without opening any schema.

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?

Provides operational context (one seg entry per one-way flight, in order; leave creditTo out for the airline's own program) and points to calculate_flight_distance for the mile figures. However, it never states when to choose this tool over a sibling calculator or its exclusions, leaving the airline-selection decision implicit.

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

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

Annotations already declare the safe read-only/idempotent profile, so the bar is lower, and the description adds real behavioral context: the exact earning formula, tier factors, the rule that extras earn nothing on codeshare flights, tier-point thresholds, and the 'Unofficial' status plus cwsi.net data source. It does not contradict the annotations.

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 purpose and formula are front-loaded, and each sentence carries computation rules or constraints rather than filler. It is dense and somewhat run-on, and repeats tier-factor values already in the schema, but it is appropriately sized for a rule-heavy calculator.

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 an output schema present, return values need not be explained, and the description covers the earning rules, codeshare/program branches, currency constraint, and source disclaimers. Coverage is complete enough for an agent to invoke the tool correctly across its branches.

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 the schema descriptions are themselves very detailed (price, extras, status, creditTo all fully documented). The description restates much of this, including the tier-factor mapping already present in the status enum. It adds the combined price+extras formula linking parameters, which earns it above a bare baseline, but most content duplicates the schema.

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 opens with a specific verb+resource: Avios and tier points earned for a Finnair ticket, computed from fare x tier factor. An agent can immediately tell this is the Finnair-specific earnings calculator. It does not explicitly name sibling tools, but the airline scope in name/title makes the distinction obvious.

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 concrete usage conditions: set flt=CS for codeshare flights booked from 3 June 2025, leave creditTo out for Finnair's own program, and 'Give the price in EUR, not US dollars.' It also routes partner-program crediting through creditTo. It stops short of explicitly contrasting with the sibling calculate_*_miles tools, so not a 5.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: the data source (cwsi.net's Great Circle Distance Calculator) and the fact that results are broken out per leg and in total.

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?

Two tight sentences with the capability statement front-loaded and the input syntax second. Nothing is wasted, though the syntax detail partially duplicates the schema description.

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 an output schema present, the description needn't explain return values, and it does state what is returned (miles, nautical miles, kilometres, per leg and total). Annotations cover safety and an output schema covers results, so an agent has everything needed to invoke it.

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 the schema already documents the route format, delimiters, code length, and trip/code limits. The description's examples largely restate what the schema says, so the baseline 3 applies; it adds only the concrete ATL-SFO~SJC-ATL pattern.

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 verb (calculate) and resource (great-circle flight distance) and names the three output units plus leg-by-leg and total aggregation, which no sibling does. It is clearly distinguishable from the ~55 airline-points calculators that share the 'calculate_' prefix.

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?

Provides detailed input-format guidance ('-' joins legs, '~' separates trips) but never states when to choose this tool over the airline mileage calculators in the sibling set. The intended use (raw distance vs. loyalty accrual) is only implied.

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

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

Annotations already declare a safe, idempotent, closed-world read, so the description earns credit for what it adds: the earning formula, that it relies on cwsi.net's calculator and the airline's published rules, and the honest 'Unofficial' caveat. It does not, however, describe rate limits, accuracy caveats beyond 'unofficial', or pagination-type traits.

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?

Purpose is front-loaded and the dense paragraph keeps formula, band definitions, and input requirements together with little redundancy. It is long and somewhat wall-of-text, but each clause carries operative content.

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 11 parameters, nested segs, and an output schema present, the description still covers inputs, units, ordering, the creditTo alternative flow, and the unofficial-service caveat. Nothing an agent needs to invoke it correctly appears missing, and return values are properly delegated to the output schema.

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 baseline is 3, but the description adds genuine meaning beyond the schema: the level-to-rate mapping (Explorer 4 ... Ultimate 9), that miles derive from base fare plus carrier surcharge excluding taxes, and the distance-band definitions. These clarify how price, level, and segs interrelate rather than merely restating fields.

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 verb (Estimate) and resource (Flying Blue Miles and XP) scoped to Air France or KLM tickets, immediately telling an agent which of the many sibling airline calculators to use. It even disambiguates the AF/KL dual-branding with 'set airline to KL for KLM'.

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?

Gives concrete preconditions and unit guidance (price in EUR not USD, miles via calculate_flight_distance, one seg per one-way flight in order) and explains when the creditTo partner path applies. It routes to a sibling for distances but never explicitly frames when *not* to use this tool versus another airline's calculator.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, covering the safety profile. The description adds that the result is an estimate based on cwsi.net's calculator and published rules and is 'Unofficial' — useful context about reliability. It does not contradict the closed-world annotation despite mentioning an external calculator as methodology source.

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 that leads with the action and resource, followed by methodology and the 'Unofficial' caveat. No filler or repetition. Slightly dense parenthetical but nothing wasted.

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 values need not be described, and all four parameters are fully covered by the schema. For a self-contained pure-calculation tool, the description supplies the essentials (what it computes, methodology, unofficial status). Only the lack of routing versus sibling airline calculators leaves a minor gap.

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%, with enum meanings spelled out for card, fare, and status and a detailed note on what price includes/excludes. The description adds no parameter-level detail beyond this, so the baseline 3 for a fully documented schema is appropriate.

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 verb (estimate) and resource (what a Frontier Airlines ticket earns in miles/points plus status credit), so the agent immediately knows the output type. The airline specificity distinguishes it from the large sibling family of airline calculators. It does not, however, explicitly route against any named alternative.

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 says what the tool does but never states when to pick it over a sibling or any prerequisite (e.g., must be a Frontier booking). With ~50 near-identical calculators, some routing guidance would materially help; none is given, leaving usage to be inferred from the tool name.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond them: it is unofficial, it mirrors cwsi.net's calculator and Iberia's published rules, Executive fare is excluded, Infinita tiers are unsupported, and omitting IATA codes silently degrades the Shuttle to an ordinary short flight.

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?

It is one dense block that mixes earning formulas, eligibility caveats, and parameter instructions, so it is not cleanly front-loaded by task. Substantial content duplicates the schema's own enum descriptions (tier factors, fare brands, segs fields), which costs it efficiency rather than adding value.

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 12-parameter, nested-segment tool with an output schema, the description covers the earning model, the Shuttle special case, currency handling, and the partner-credit branch, so an agent has what it needs. Minor gaps remain around ordering/pagination of results, which the output schema likely handles.

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%, so the baseline is 3, but the description genuinely extends it — the Avios/Elite Point formulas, the tier-per-euro mapping, and the consequence of missing from/to codes ('without them that flight counts as an ordinary short flight') add meaning the schema does not carry. The 'price in EUR, not US dollars' warning is also a useful semantic guardrail.

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 verb and resource ('Iberia Club Avios and Elite Points for an Iberia (IB) ticket') and spells out the two outputs it computes. The airline and loyalty program are named explicitly, so an agent can separate it from the dozens of sibling calculate_*_miles tools without opening the schema.

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?

Gives clear operative context: segs must be one entry per one-way flight in order, and it routes the agent to calculate_flight_distance for the miles. It also frames the creditTo path (alaska vs Iberia's own program) and states what to leave out. It stops short of explicit when-not-to-use guidance, but the airline scoping makes alternatives obvious.

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

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

Annotations already declare read-only/idempotent, so the description is free to spend its words on real behavioral caveats and does: which classes earn nothing, which are Premium-Economy-only worldwide, the status bonus being deliberately not added because unpublished, the Miles & More price-vs-class ambiguity, the tc continent ambiguity, and that the source is unofficial (cwsi.net). This is exactly the beyond-annotation context an agent needs.

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?

Purpose is front-loaded in the first clause, but the body is a single dense paragraph of semicolon-chained clauses mixing program history, earnings rules, geography exceptions and caveats. Some sentences (the segs structure, the A/F/I/O/R/X earn-nothing list) restate the schema, and the airline-history aside is lower value than the routing rules.

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 12-parameter tool with nested segs, an output schema and full schema coverage, the description covers the hard parts: segment shape, class outcomes, geography edge cases and the partner-program escape hatch. Gaps are minor, e.g. trip=rt behavior and status/points interplay are left entirely to the schema.

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%, so the baseline is 3, but the description adds meaning the schema lacks: the North-Africa-counts-as-Europe rule for country classification, the fact that hp/qp/pts/status affect only tier progress, and that segs must be ordered one-way legs. It does not explain trip or the creditTo vs cls precedence in much depth, so it edges just above baseline rather than replacing the schema.

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 (Miles & More miles, Points, Qualifying Points, HON Circle Points) for a specific airline (ITA Airways) and explains the program context (ITA joined Star Alliance, Volare ended) so it is unmistakable against the ~50 sibling airline calculators. Also names what is computed: fixed miles by class within Europe, distance x class factor worldwide.

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?

Gives concrete invocation guidance: segs must be one entry per one-way flight in order with great-circle miles, and it explicitly routes to calculate_flight_distance for those miles. It also frames the creditTo partner-program alternative and states the tool takes no price. It never explicitly says to use a different sibling for a different airline, but the airline-specific framing makes that implicit.

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

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. The description still adds real context: it declares itself 'Unofficial', flags that JAL publishes no country list and that the Asia/Oceania rate follows cwsi.net's reading, and notes 'Takes no price'. It does not describe output shape, but the output schema exists for that.

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?

Dense but front-loaded: the tool's scope leads, then the formulas, then input format. Sentences carry genuine domain information (rate bands, bonus structure, VVO edge case) rather than padding, though the description runs long enough that a little compression is possible.

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 9-parameter calculator with full schema coverage and an output schema, the description covers everything an agent needs: what it computes, the formula, the exact seg input contract, the Vladivostok caveat and the partner-credit switch. Nothing material is missing.

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% with 9 well-documented parameters, so the baseline is 3. The description restates the FLY ON formula and the VVO/Vladivostok rationale but adds little syntactic or semantic detail beyond what the schema already spells out for cls, status and creditTo.

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 verb+resource: computing flight miles, Mile-Up Bonus and FLY ON Points for a JAL-operated itinerary. The JAL naming plus the JAL-specific FLY ON Points concept makes it trivially distinguishable from the ~50 sibling calculate_*_miles tools.

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?

Tells the agent exactly how to supply input (one seg per one-way flight, in order, with great-circle miles, ISO country codes and IATA codes) and routes to calculate_flight_distance for the distance values, plus 'leave creditTo out for the airline's own program'. No explicit when-not or sibling-alternative routing beyond creditTo, which keeps it below 5.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is carried structurally. The description adds genuinely useful behavior: the exact earning percentages per booking class, domestic-flight points treatment, the 'takes no price' boundary, and source provenance (cwsi.net, airline rules, unofficial). It stops short of explaining output shape or partner-program edge behavior, so 3 is fair.

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 single long sentence bundling the mileage table, points rules, and status tiers is dense and front-loads the core purpose well, but it is sprawling and mixes the earning formula, progress tracking, and sourcing caveats into one run-on. Functional but not tightly structured.

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 read-only calculator with a full 11-param schema and an output schema present, the description gives the essential context: the earning model, the flight-points distinction, status tiers, and the upstream distance dependency. It needn't explain return values since an output schema exists; the only minor gap is partner-credit behavior nuance, which the schema handles.

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 all 11 parameters in depth (cls enum, segs nested fields, creditTo statuses). The description adds only a little beyond that (restating the segs ordering requirement and the distance source), which matches the baseline-3 rule when the schema does the heavy lifting.

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 verb+resource (Korean Air SKYPASS miles and flight points for one or more flights) and even enumerates the exact earning formula and table percentages. Among ~50 sibling calculate_*_miles tools, the airline-specific naming and the paired sibling calculate_flight_distance make its scope unambiguous.

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?

Effectively says when to use this over the distance tool by specifying 'one entry per one-way flight, in order, with its great-circle miles (calculate_flight_distance gives them)', naming the upstream alternative and the required handoff. It also notes what it does not cover (domestic mileage table). No explicit 'do not use this for X' beyond that, so not a full 5.

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

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 is covered. The description adds genuinely useful context beyond that: it discloses the data source ('cwsi.net's calculator and the airline's published rules'), that it is 'Unofficial', and that it 'Takes no price', which matters for a 12-parameter tool.

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?

Purpose is front-loaded, which is good, but the body is a dense run-on that intermixes earning rules, currency exclusions, geography exceptions, parameter instructions and source disclaimers across many parenthetical clauses. Much of the class-by-class earning detail duplicates what is already in the cls enum, so the size is partly redundant rather than purely additive.

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 values need not be explained, and the description covers what remains: the earning model, the rerouting sibling, the segs input shape, the creditTo partner programs, and the source for great-circle miles. For a 12-parameter tool it is complete enough to invoke correctly.

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 baseline is 3, and the schema itself already documents most parameters. The description still adds meaning the schema does not fully convey, notably the rationale for tc (Algeria/Egypt/Libya/Morocco/Tunisia count as Europe; set EU or AS for the two-continent countries) and the requirement that segs be one entry per one-way flight in order with great-circle miles.

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 verb and resource: computing Miles & More miles, Points, Qualifying Points and HON Circle Points for flights operated and ticketed by LOT (ticket 080), by booking class. It also distinguishes itself from the sibling calculate_lufthansa_miles and even names the shared prerequisite calculate_flight_distance, so an agent can route without opening any schema.

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?

Explicit scope conditions ('operated and ticketed by LOT Polish Airlines (ticket number 080)'), an exclusion that reroutes the agent ('LOT flights booked through a Lufthansa Group channel earn by fare instead (calculate_lufthansa_miles)'), and a special-case note about tc for Turkey/Cyprus/etc. It also notes classes that earn nothing. Alternative paths are named, not implied.

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

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

Beyond the read-only annotations, the description discloses the calculation method: award miles are fare EUR x4 or x6 by status with a 125-mile minimum, and Points per flight vary by cabin and continental/intercontinental classification. It also notes the external source and that the tool is unofficial, which is valuable behavioral 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?

The description is front-loaded with purpose and calculation rules, and every sentence is relevant to a complex calculator. It is dense and repeats some schema content, but for a 15-parameter tool it remains appropriately sized.

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?

The description gives enough detail to call the tool correctly for the main Miles & More earning path, and the rich schema plus output schema fill in the rest. It does not mention the creditTo partner-program mode, but that alternate path is fully documented in the input schema.

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 all 15 parameters in detail. The description reinforces a few input rules, such as segs versus cont/icf and price in EUR, but mostly repeats information already present in the schema and adds little for optional fields like hp, qp, pts, or creditTo.

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 uses a specific verb, 'Estimate', and names the exact resource: Miles & More award miles, Points, Qualifying Points and HON Circle Points for a Lufthansa, SWISS, Austrian or Brussels Airlines ticket. This is clearly distinguishable from sibling airline calculators by airline group and loyalty program.

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 states the eligible airline ticket context, explains how to provide flights either via segs or via cont/icf counts, and warns to give the price in EUR rather than USD. It does not explicitly name when to use a different sibling calculator, but the airline-specific framing supplies clear usage context.

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