Server Quality Checklist

Tool Scores

• get_airport_info_lightB
  3.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the transparency burden. It discloses the output (airport name, ICAO, IATA codes) and the required non-empty code, but mostly repeats schema constraints (required, minLength). It does not mention error behavior for unknown codes, read-only status, or any side effects. For a simple getter, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one concise sentence plus a direct warning, with no filler. It leads with the core output and immediately states the critical requirement. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and no output schema, the description covers the essential return fields and the required parameter. However, it lacks guidance on when to prefer this 'light' tool over get_airport_info_full, and does not clarify behavior for invalid or not-found codes. These gaps keep it from being fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (single 'code' parameter clearly described as 'Airport IATA or ICAO code'). The description adds no new meaning beyond the schema; it merely restates that the code must be non-empty, which is already captured by required and minLength. Thus, baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool returns airport name, ICAO, and IATA codes, using the verb 'returns' with a specific resource and output items, making the purpose clear. However, it does not explicitly differentiate from the sibling get_airport_info_full, so it stops short of full sibling distinction.

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

  Usage Guidelines2/5

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

  The only usage guidance is 'REQUIRED: code must be provided and non-empty,' which is a precondition for invoking the tool rather than guidance on when to select it over alternatives. No mention of when to use the 'light' version vs get_airport_info_full, and no exclusions or alternatives are provided.

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

• get_historic_flights_positions_lightB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden. It discloses the historical data availability (since 2016, plan-dependent) and the mandatory parameter requirements, but omits details about output format, pagination, or potential rate limiting. This is partial but useful disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences and front-loaded with the primary purpose. The IMPORTANT note is succinct and essential, earning its place. No redundancy or filler, though it could briefly mention what 'light' means relative to the full variant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 17 parameters and no output schema or annotations, the description covers the core purpose and critical invocation requirements. Yet it lacks any mention of response shape, error behavior, or how 'light' limits the returned fields. It is adequate but not fully complete for a tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all 17 parameters. The description adds the important constraint that limit alone is insufficient and at least one other search parameter must be given, which is valuable context beyond the schema. However, it does not explain individual parameter syntax beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns historical aircraft flight movement data including latitude, longitude, speed, and altitude. It differentiates from live-flight siblings by specifying 'historical' and from 'full' tools by the 'light' suffix, though it doesn't explicitly contrast with the full version.

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

  Usage Guidelines3/5

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

  It provides an explicit usage constraint (timestamp required, plus at least one non-limit parameter) which is useful for correct invocation. However, it does not say when to prefer this tool over alternatives like get_historic_flights_positions_full or get_live_flights_positions_light.

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

• get_flight_summary_countA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the required parameters and the recommendation for an additional parameter, but does not disclose the return format, error behavior if requirements are not met, or any other behavioral traits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long, front-loaded with the core purpose, and every word earns its place. The IMPORTANT note is concise and directly actionable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema provides rich parameter details, and the description covers the count semantics and constraints. However, given the many sibling tools, the description does not clarify when to use this over get_live_flights_count or get_historic_flights_count, leaving some contextual ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds value by emphasizing the required datetime parameters and the recommendation to include at least one additional search parameter, which is not explicitly stated in the schema for the optional parameters. However, this addition is minimal.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns the number of flights for a flight summary query, using a specific verb ('Returns') and resource ('number of flights'). It distinguishes from siblings that provide flight details or positions, though it does not explicitly differentiate from the live/historic count tools.

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

  Usage Guidelines4/5

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

  The description provides explicit usage guidance: flight_datetime_from and flight_datetime_to are required, and at least one additional search parameter should be provided. This is helpful for correct invocation, though it does not mention alternative tools or exclusions.

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

• get_flight_tracksA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden for behavioral disclosure. It only states the return type and re-emphasizes the required parameter, both already inferable from the name and schema. No info on error handling, rate limits, or output structure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the core purpose. The second sentence is slightly redundant but concise and does not harm clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one parameter, but without an output schema or annotations, the description should explain what 'tracks' includes (e.g., lat/lon, timestamps). The current description is minimally viable but leaves a gap in expected return content.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with flight_id described as a hexadecimal Flightradar24 ID. The description adds no new semantic meaning, only the non-empty reminder which duplicates schema's required and minLength constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'Returns' and resource 'positional tracks of a specific flight', clearly distinguishing it from sibling tools like get_flight_summary_* and get_historic_flight_events_*. The REQUIRED note reinforces the specific-flight scope.

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

  Usage Guidelines3/5

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

  Provides context that flight_id is mandatory, but this is a parameter constraint, not guidance on when to choose this tool over alternatives. No exclusions or alternatives are mentioned, so usage is implied rather than explicit.

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

• get_historic_flight_events_fullA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses that events are sorted by event_timestamp and grouped by flight_id, and that inputs must be non-empty. However, it omits return format, pagination, permissions, or potential error cases, which are important behavioral details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences: the first states the core functionality and output characteristics, the second conveys a key constraint. It is front-loaded, free of fluff, and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the essential what-it-does and sorting/grouping behavior, but lacks details on return structure, which is notable since no output schema exists. It also does not clarify the difference from the 'light' sibling tool, making the description average in completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with descriptions for both parameters, including the list of event types and the max ID limit. The description additionally emphasizes that both parameters are required and non-empty, but does not add meaningfully beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns selected historical flight events with specific event types, detailed information, sorted and grouped. This distinguishes it from sibling tools like position checkers and the 'light' version by emphasizing detail and event categories.

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

  Usage Guidelines2/5

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

  There is no explicit guidance on when to use this tool versus alternatives such as get_historic_flight_events_light or position tools. The only guidance is a required-parameter note, which is more of a validation rule than usage context.

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

• get_airport_info_fullA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the requirement for a non-empty code and lists the returned fields, implying a read-only operation. However, it does not explicitly state that no data is modified, nor does it describe error handling or response format. For a simple getter, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, information-dense sentence followed by a clear requirement. It is front-loaded with the key purpose and avoids any unnecessary filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and no output schema, the description sufficiently covers the purpose, input requirement, and output fields. It does not explicitly contrast with 'get_airport_info_light' but is otherwise complete for invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameter 'code' is already described as 'Airport IATA or ICAO code.' The description repeats the requirement but adds no extra meaning 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns detailed airport information with specific attributes (full name, ICAO/IATA codes, localization, etc.), using a specific verb and resource. The name 'get_airport_info_full' and the word 'detailed' distinguish it from the sibling 'get_airport_info_light'.

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

  Usage Guidelines2/5

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

  The description provides a required input condition ('REQUIRED: code must be provided and non-empty') but gives no guidance on when to use this tool versus alternatives like 'get_airport_info_light'. It does not mention any exclusions or comparison among siblings.

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

• get_historic_flight_events_lightA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It adds useful info about sorting by event_timestamp and grouping by flight_id, and emphasizes non-empty required fields. However, it omits details such as response structure, pagination, rate limits, or what 'light' means in terms of returned fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, both information-dense. The first sentence lists event types and specifies sorting/grouping; the second provides a clear constraint. There is no fluff or repetition, and key details are front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is largely sufficient for a simple 2-parameter tool with full schema coverage. It explains the event types, result ordering, and required inputs. However, it lacks a comparison with the 'full' sibling, which would help an agent understand if this lighter variant is appropriate. The absence of an output schema is mitigated by the clear purpose.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both flight_ids and event_types have descriptive text in the schema. The description only repeats the requirement that they must be provided and non-empty, which is already captured by 'required' and 'minLength'. It adds no new semantic meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Returns') and the resource ('historical flight events'), and specifies the event types and ordering/grouping behavior. However, it does not explicitly distinguish this 'light' version from the sibling 'get_historic_flight_events_full', so sibling differentiation is missing.

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

  Usage Guidelines3/5

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

  The description implies a use case for retrieving historical events, but does not provide guidance on when to choose this tool over alternatives, such as the 'full' variant or flight positions tools. The 'REQUIRED' note relates to parameter constraints, not usage context.

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

• get_live_flights_positions_lightA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It discloses the important constraint that at least one non-limit parameter is required, which is valuable. However, it does not clarify what 'light' means, potential response limitations, or any other behavioral characteristics.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: one purpose sentence, an important note, and a list of parameter names. The list is long but necessary to convey valid search parameters. It front-loads the main purpose and wastes no words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 16 parameters, no annotations, and no output schema, the description provides the key invocation constraint and hints at return content (latitude, longitude, speed, altitude). However, it does not explain the 'light' vs 'full' distinction or the response structure, leaving some ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100%, so all 16 parameters already have detailed descriptions. The tool description merely lists parameter names and notes 'limit' as an exception, adding no new semantic information beyond what the schema provides. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns real-time aircraft flight movement data with specific fields (latitude, longitude, speed, altitude), using the specific verb 'Returns'. It identifies the resource precisely, but it does not explicitly distinguish from the sibling 'full' variant beyond the name 'light'.

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

  Usage Guidelines4/5

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

  The description provides explicit usage guidance: at least one search parameter (other than limit) must be provided and non-empty, and it lists all acceptable filter parameters. It does not mention alternatives or when to prefer the 'full' variant, but the context is clear for correct invocation.

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

• get_historic_flights_positions_fullA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the transparency burden. It discloses important behavioral traits: the mandatory timestamp + additional parameter requirement, and subscription-dependent historical data range. However, it does not explain output structure, pagination, limit behavior, or potential error cases, leaving gaps for a 17-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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise: two sentences that front-load the core function, then add historical context and a critical usage constraint. Every sentence delivers useful information without redundancy, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 17 parameters and no output schema, the description covers key return fields (lat/lon/speed/altitude plus flight details), data availability, and mandatory query constraints. It is reasonably complete for a read-only retrieval tool, though it could better clarify the distinction from the 'light' variant and output formatting.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, providing a baseline of 3. The description adds value by explaining that timestamp is required and that at least one additional search parameter must be non-empty, and clarifies that 'limit' alone doesn't count. This goes beyond the schema, which only lists 'timestamp' as required without the extra constraint.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns historical aircraft flight movement information including latitude, longitude, speed, altitude, and key flight/aircraft details. This specifies the action and resource, but it does not explicitly distinguish from sibling tools like the 'light' version, only implying more detail through the 'full' name and mention of additional fields.

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

  Usage Guidelines3/5

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

  The description provides explicit usage constraints: timestamp is required and at least one additional search parameter (other than limit) must be provided and non-empty. It also notes data availability from May 11, 2016 depending on subscription. However, it does not guide when to use this tool versus alternatives (e.g., get_historic_flights_positions_light), lacking exclusions or comparative guidance.

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

• get_airline_infoA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It says 'Returns' which implies a read operation, but doesn't disclose behavior like error handling, output format, or whether any dependencies exist. For a simple lookup tool this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the primary purpose and then the key constraint. Every word earns its place with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter lookup tool, the description adequately states the return fields and the required input. It lacks details about error responses or edge cases, but the tool's simplicity does not demand much more. The absence of an output schema means the description usefully lists the returned fields.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers the single parameter 'icao' with 100% coverage, including minLength and required. The description's emphasis on 'must be provided and non-empty' adds no new semantic information beyond what the schema declares, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: 'Returns airline name, ICAO and IATA codes.' It uses a specific verb ('Returns') and names the exact resource and output fields. The sibling tools are all flight- or airport-focused, so this airline-specific tool is clearly differentiated.

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

  Usage Guidelines3/5

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

  The description does not explicitly state when to use this tool over alternatives or mention any exclusions. It provides the hard requirement that ICAO code must be non-empty, which guides usage, but there is no comparison to sibling tools or guidance on when choosing airline info is appropriate.

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

• get_flight_summary_fullA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It adds meaningful context by stating data availability from 2024-04-07, that both real-time and extensive historical data are accessible, and a non-obvious requirement for an additional search parameter. While it does not detail output formats or rate limits, the disclosed traits go beyond mere restatement.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise (three sentences) and front-loads the core purpose. Each sentence is informative: the main functionality, data availability range, and a critical usage constraint. There is no wasted content, and the structure naturally guides the agent toward proper invocation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 12 parameters and no output schema, the description provides a complete high-level picture: it defines the data scope, the types of information returned, the availability window, and a mandatory filtering condition. The parameter schema covers individual details, so the description adequately supplements it for selection and initial invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents all 12 parameters with descriptions, so baseline is 3. The description adds value by explicitly requiring at least one additional search parameter beyond sort and limit, which is not present in the schema's required list. This clarifies a non-obvious constraint for effective invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns comprehensive timings and locations of aircraft takeoffs and landings with detailed flight, aircraft, and operator information. It distinguishes from siblings implicitly through the word 'full' and 'comprehensive', but does not explicitly name alternative tools for comparison.

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

  Usage Guidelines3/5

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

  The description notes that both real-time and historical data are available, and includes an IMPORTANT constraint about required parameters and additional search filters. However, it does not provide explicit guidance on when to choose this tool over siblings like get_flight_summary_light or get_flight_summary_count, nor does it state exclusions for alternative use cases.

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

• get_historic_flights_countA
  3.9/5.0
  Behavior3/5

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

  Without annotations, the description carries the burden of behavioral disclosure. It discloses the required parameter combination rule, which is not inferable from the schema alone. However, it does not mention output format, error conditions, or rate limits, leaving gaps in transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary purpose and followed by an important warning. 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.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 17 parameters and no output schema, yet the description provides only the count purpose and the mandatory-filter constraint. It does not explain the return structure, the meaning of 'flight positions' as opposed to flights, or the optional combination of filters. Given the tool's complexity, the description is incomplete but the schema covers parameter details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes all 17 parameters with 100% coverage, so the description's contribution is limited. It adds value by clarifying that 'limit' does not count as the required additional search parameter, which is an important interaction rule. This elevates the semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning a count of historical flight positions, using a specific verb and resource. The term 'historical' differentiates it from live count tools, and 'count' vs 'positions' distinguishes it from sibling position tools. Though 'flight positions' might be ambiguous, 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.

  Usage Guidelines3/5

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

  The description provides a crucial usage constraint: timestamp is required and at least one additional search parameter must be non-empty. However, it does not explicitly compare this tool to alternatives or state when to prefer it over position-returning siblings. The guidance is operational rather than comparative.

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

• get_live_flights_countA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses the mandatory search parameter rule but does not explain how multiple filter parameters combine (AND/OR) or how the limit parameter affects the count. These are important behavioral details for correct usage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loaded with the main purpose and followed by the critical usage constraint. Every word earns its place, with no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 16 parameters and no output schema or annotations, the description covers the core purpose and the mandatory filter rule but omits how filters interact and how limit is applied. It is adequate for a simple count tool but leaves meaningful gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The tool description adds the note that limit is not a search parameter, which is useful, but it does not provide any additional meaning beyond the schema's property descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns a count of real-time aircraft flights matching criteria, with a specific verb and resource. It distinguishes from siblings like get_historic_flights_count via 'real-time' and 'count'.

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

  Usage Guidelines4/5

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

  The description gives a clear context for use: when you need a count of live flights, and it provides the important rule that at least one search parameter (other than limit) must be provided. It does not explicitly name alternatives or exclusions, but the context is clear.

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

• get_live_flights_positions_fullA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of disclosing behavior. It clearly states that the tool returns real-time aircraft information and imposes a mandatory filter requirement, which is valuable. However, it does not mention rate limits, response formatting, pagination, error behavior when no filter is given, or authentication requirements. The core behavior is transparent, but significant operational details are absent, leaving it at a 3.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first is front-loaded with the tool's primary output and data fields, the second delivers a high-visibility usage requirement. There is no filler, no repetition of schema details, and each sentence earns its place. Excellent conciseness and structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (16 parameters) and the absence of an output schema and annotations, the description does a solid job: it lists the returned fields (latitude, longitude, speed, altitude, etc.) and the mandatory search-parameter rule. However, it omits any explanation of how this differs from the 'light' variant or what defaults apply when limit is omitted, though those limits are in the schema. Overall, it is sufficiently complete for an experienced agent but not exhaustive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema description coverage, each parameter is already documented individually. The description adds value by categorizing a subset of parameters as 'search parameters' and excluding 'limit' from that group, while also stating the non-empty requirement—a constraint not evident from the schema's optional flags. This goes beyond simply repeating param descriptions, so a 4 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description begins with a specific verb 'Returns' and identifies the resource as 'real-time aircraft flight movement information' with a concrete list of data fields (latitude, longitude, speed, altitude, origin, destination, callsign, registration, aircraft type). This is a clear statement of what the tool does, but it does not explicitly contrast with sibling tools like get_live_flights_positions_light or get_live_flights_count. The 'full' suffix and field enumeration imply a richer variant, but the lack of explicit sibling differentiation keeps it from a 5.

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

  Usage Guidelines4/5

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

  The description provides a critical usage constraint: 'At least one search parameter (other than limit) must be provided and non-empty,' followed by a list of valid filter parameters. This is explicit guidance on when the tool can be invoked. However, it offers no direction on when to use this tool versus the 'light' or 'count' alternatives, nor does it state exclusions (e.g., for historic data or simple counts).

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

• get_flight_summary_lightA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and adds useful behavioral context: data availability start date, real-time/historical support, and the IMPORTANT constraint about additional search parameters. It does not disclose pagination or output structure, but for a read-only summary tool this 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences plus a highlighted IMPORTANT note. It front-loads the purpose, then provides data availability and essential usage constraint, with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 12 parameters and no output schema, the description adequately explains purpose, data range, and usage requirements. It does not clarify what 'light' means versus the full sibling, but the description covers enough for an agent to select and invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds the global constraint that at least one additional search parameter (other than sort/limit) must be provided, which is not in the schema. This provides value beyond the schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns key timings and locations of takeoffs/landings along with primary flight/aircraft/operator info. It is specific but does not explicitly differentiate from the sibling get_flight_summary_full, so it lacks sibling distinction.

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

  Usage Guidelines4/5

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

  The description provides clear context: real-time and historical data, availability starting 2024-04-07, and required datetime parameters plus at least one additional search parameter. It does not explicitly state when to use this light version vs the full version, so no exclusions/alternatives are mentioned.

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