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

Annotations already provide readOnlyHint and openWorldHint, and the description does not repeat them. It adds no extra behavioral details like not-found behavior or rate limits, but it doesn't contradict the annotations either.

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?

One sentence, front-loaded with the action and result, and zero filler. Every word earns its place.

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 one-parameter read-only lookup with a rich input schema, output schema, and annotations, the description covers the essential behavior. There are no critical gaps that would prevent correct invocation.

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?

Input schema coverage is 100%, including an example and an explicit note that IATA-only lookup is unsupported. The tool description only says 'by its ICAO code,' adding no meaning beyond 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?

Uses a specific verb ('Get') and resource ('airline's name and IATA code') with a clear lookup key (ICAO code). This cleanly differentiates it from sibling tools that concern flights, airports, or searches.

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 the usage context: use when you have an ICAO code and need the airline name/IATA code. It doesn't name alternatives, but none of the sibling tools overlap directly, so the guidance is sufficient.

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 readOnlyHint=true and openWorldHint=true, and the description's 'Get information' is consistent with that. The description adds no behavioral context beyond the annotations, so it meets the baseline but provides no extra transparency about limitations 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?

The description is a single, front-loaded sentence with no filler. It communicates the tool's purpose and lookup key efficiently, earning every word.

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 simple read-only lookup tool, the description plus the detailed input schema and output schema provide enough information for an agent to call it correctly. No critical context appears 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%, and both parameters are already documented with meaningful descriptions, including the enum for detail_level. The description adds only the word 'exact,' which slightly reinforces the code format, but it does not materially add value beyond 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 names a specific verb ('Get') and resource ('information about an airport') and adds a precise lookup criterion ('exact IATA or ICAO code'), which makes the core purpose clear. It distinguishes the tool from sibling flight/airline tools by resource type, though it does not name a sibling or explicitly contrast itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies a clear use case: call this when you need airport details and have a specific IATA or ICAO code. However, it provides no explicit guidance about alternatives or when not to use this tool, leaving some inference to the agent.

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 mark the endpoint as read-only and open-world, and the description adds meaningful behavioral detail beyond those hints: the rate limit and the per-endpoint grouping. No contradiction 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?

Two short sentences: the first states the purpose, and the second adds a critical rate-limit caution. Every word earns its place with no 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 zero-parameter read-only endpoint with an output schema, the description covers the purpose, the scope (per endpoint), and the key operational constraint. Nothing an agent needs 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?

The tool has zero parameters and schema coverage is 100%, so the schema already fully describes everything an agent needs. The description adds no parameter semantics, but none are necessary.

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 ('Get') and resource ('a summary of FR24 API credit usage per endpoint'). It is immediately distinguishable from all sibling tools, which focus on flight, airport, and airline data rather than API usage.

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?

Clearly indicates when to use the tool: when the agent needs a per-endpoint summary of FR24 API credit usage. It also supplies operational guidance by warning about the 1-call-per-minute rate limit. It does not name alternatives, but no sibling tool serves the same purpose.

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 description discloses a key behavioral trait: the tool only returns a result while the flight is in the air, which is critical for an agent to understand. The annotations (readOnlyHint=true, openWorldHint=true) already indicate safety and non-exhaustiveness, and the description adds the real-time constraint. It doesn't mention rate limits or credit costs, but the detail_level parameter description covers credit costs partially.

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 two sentences, front-loads the core purpose, and includes the key constraint and alternative tool. No wasted words.

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 is complete for a read-only lookup tool with a rich schema and output schema. It covers the main usage caveat (airborne only) and routes to the right sibling. It could mention that the tool may return no result if the flight is not found, but the 'only returns a result while in the air' statement implies this. 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%, so the schema already documents all parameters. The description adds context about the flight_number/callsign alternatives and the real-time nature, but doesn't add much beyond the schema. 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?

The description clearly states the tool's function: retrieving real-time position data for a currently airborne flight by flight number or callsign. It explicitly distinguishes itself from get_flight_summary for non-airborne flights, which helps an agent differentiate it from 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?

The description explicitly states when to use this tool (for currently airborne flights) and when not to use it (for completed, scheduled, or historical flights), directing the agent to get_flight_summary instead. This is clear, actionable 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 readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds useful scope ('currently airborne', 'bounding box') but does not mention the optional limit's default/max or the credit-cost difference between detail levels; those details are left to the schema, so this is a minor gap rather than a contradiction.

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?

One short sentence that front-loads the action and object while capturing the essential scope. There is no filler, redundancy, or unnecessary elaboration.

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 rich output schema, fully described parameters, and readOnly/openWorld annotations, the description is complete enough for an agent to invoke the tool correctly. The main omissions—explicit sibling differentiation and the default limit behavior—are minor because the schema already captures the limit and detail-level semantics.

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 every parameter, including limit and detail_level, has a clear description. The free-text description only restates the bounding-box concept and adds no parameter meaning beyond what the schema already provides, so 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?

The description states a specific action ('Get') on a specific resource ('currently airborne flights') with a precise geographic scope ('bounding box'). This clearly distinguishes it from sibling tools like get_flight_tracks or get_flight_data, which target different data shapes.

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 the use case: querying live flights within a geographic area. However, it does not explicitly say when to prefer this tool over siblings like search_flights or get_flight_data, nor does it provide exclusions or alternative 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 readOnlyHint and openWorldHint, so the safety profile is established. The description adds the useful scope that only completed flights appear in the history, but it does not go into rate/credit limits, ordering caveats, or other behavioral details. This is helpful but not rich beyond what annotations already signal.

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: the first states the action, scope, and filters; the second states the completion condition and routes to the live alternative. Every clause earns its place and the key scoping constraint is front-loaded.

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 full schema descriptions and an output schema, the description only needs to carry selection-level context, which it does: purpose, historical scope, and the alternative for live flights. It loses a point for the unsupported filter list, which makes the prose not fully trustworthy as a summary of capabilities.

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 every parameter has a strong description, so the baseline is 3; however, the prose adds an inaccurate filter list—it names callsign, airport, and aircraft type, none of which exist as parameters in the schema. This can mislead an agent into constructing invalid calls, and the accurate filter set is better conveyed by the schema alone.

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 object—'Get takeoff/landing history (flight summary)'—and narrows the resource to flights in a date/time window. It lists optional filter dimensions and explicitly contrasts with get_flight_data for live flights, so an agent can distinguish this tool from siblings immediately.

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?

'Covers completed flights; use get_flight_data for flights currently in the air' is an explicit when-to-use and alternative rule. It tells the agent the tool is for historical windows and directs live-flight queries elsewhere. No further selection guidance is needed.

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 and openWorldHint=true, so the safety profile is covered. The description adds the output shape (timestamped lat/lon/altitude/speed points) and the prerequisite of obtaining fr24_id first. It does not discuss limitations like track availability, retention, or pagination, but given the read-only annotation the added context is adequate.

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 two sentences with no filler. The purpose is front-loaded, and the prerequisite is presented as a clear second sentence. Every word contributes.

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 single-parameter read-only tool with an output schema, the description covers purpose, parameter origin, and the primary prerequisite. The annotations handle the read-only and open-world aspects. Nothing essential is missing for an agent to call this 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 coverage is 100% and the schema already documents flight_id as a hexadecimal string. The description adds value by explaining that the fr24_id must be obtained from specific sibling tools before use, which is useful operational guidance beyond 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 clearly states the tool's function: retrieving a detailed position track (series of timestamped lat/lon/altitude/speed points) for one specific flight. It explicitly ties the input to the FR24 flight ID, distinguishing it from list/search tools like search_flights and get_flights_in_zone by limiting scope to a single flight.

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 explicit guidance on when to use this tool: after obtaining the fr24_id from get_flight_data, search_flights, or get_flight_summary. It clearly communicates the prerequisite dependency. It does not, however, offer explicit 'when not to use' or alternative routing beyond the prerequisite mention.

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?

With readOnlyHint=true and openWorldHint=true annotations already covering the safety profile, the description adds useful context: the tool targets currently airborne flights and enforces a filter requirement. This goes beyond the annotations without contradicting them.

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 no filler. The key scoping detail ('currently airborne', 'FR24 live flight positions endpoint') is front-loaded, and the validation constraint is stated directly.

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 rich input schema, output schema, and read-only annotations, the description is largely complete for calling the tool correctly. The only notable gap is not mentioning sibling tools or when another endpoint would be more 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 schema already documents every parameter thoroughly. The description adds only a global filter requirement and does not enrich individual parameter meaning; 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?

The description names a specific verb and resource ('Search for currently airborne flights using the FR24 live flight positions endpoint') and the 'currently airborne' scope helps set it apart from flight-data lookup siblings. It does not explicitly name a sibling alternative, so it misses the top tier for differentiation.

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 a clear context (searching currently airborne flights) and an explicit, operational constraint: at least one actual filter must be provided. It does not state when to prefer a sibling such as get_flights_in_zone, so there is no exclusion guidance.

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