Server Quality Checklist

Tool Scores

• get_best_flightsA
  3.6/5.0
  Behavior2/5

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

  No annotations present, so description carries full burden. Does not disclose safety, error handling, rate limits, or return format details beyond 'list of flight information strings'. Minimal transparency for a flight search tool.

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

  Conciseness3/5

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

  Structured with sections but somewhat verbose, repeating 'optional' and using docstring style. Could be more succinct while retaining 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?

  Covers parameters well but lacks broader context: no explanation of 'best flights' criteria, no mention of error scenarios, and no details on return content beyond string list. Adequate but leaves gaps.

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

  Parameters5/5

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

  Provides detailed parameter documentation with examples, defaults, and allowed values (e.g., IATA codes, date format, seat types). Compensates fully for 0% schema coverage, giving significant meaning beyond simple titles.

  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?

  Clearly states it retrieves best flights from Google Flights for given origin, destination, departure date. Explicitly distinguishes from siblings by mentioning round-trip requires two calls, differentiating from get_cheapest_flights and get_general_flights_info.

  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 guidance for round-trip (make two one-way calls) but does not explicitly state when to use this tool versus siblings. No mention of when to prefer get_cheapest_flights or get_time_filtered_flights.

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

• get_cheapest_flightsA
  3.6/5.0
  Behavior3/5

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

  The description explains the return format (list of flight info strings) and parameter behavior, but lacks disclosure of side effects, permissions, or rate limits. Since no annotations are provided, the description carries full burden and is adequate but not fully transparent.

  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 well-structured with an Args/Returns format, but is somewhat lengthy. The round-trip note is useful and front-loaded. Overall, it is organized and clear.

  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 9 parameters, no output schema, and no annotations, the description covers all parameters with examples and defaults, and describes the return type. It is complete for the complexity of 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?

  The description provides detailed parameter explanations with examples (e.g., origin: 'ATL'), default values, and allowed values for trip_type, seat, etc. This adds significant value beyond the input schema, which has 0% description coverage.

  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 retrieves cheapest flight information for a given origin, destination, and departure date. The purpose is specific and distinct from sibling tools like 'get_best_flights' or 'get_general_flights_info', though it does not explicitly differentiate itself.

  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 usage guideline for round-trip requests (making two one-way calls), but does not include when to use this tool versus alternatives like 'get_best_flights' or 'get_time_filtered_flights'. It implies one-way is the default.

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

• get_general_flights_infoA
  3.8/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Details parameters and return format but does not disclose behavioral traits like rate limits, error handling, or authentication needs.

  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?

  Well-structured with clear intro, args list, and returns. Slightly verbose (e.g., 'general/comprehensive'), but information is effectively 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?

  Covers all 10 parameters and return format with list of strings. Missing output schema and behavioral context like error messages or pagination, but adequate for a data-fetching tool.

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

  Parameters5/5

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

  Schema has 0% description coverage; the description provides comprehensive, clear parameter explanations including format examples, defaults, and constraints (e.g., IATA codes, date format, seat types). This adds high value beyond 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?

  Description clearly states tool fetches general/comprehensive flight information with key parameters. Implicitly distinguishes from siblings by being general, but does not explicitly differentiate.

  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 guidance for round-trip flights (making two calls), but lacks explicit when-to-use vs siblings like get_cheapest_flights or get_best_flights.

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

• get_time_filtered_flightsA
  4.2/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 explains the behavior: returns list of flight strings, with logic for state parameter. It does not disclose safety, idempotency, or side effects, but no contradictions are present.

  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 well-structured with Args and Returns sections, and front-loaded with purpose. Though somewhat lengthy, it is efficient for the complexity.

  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?

  Despite no output schema, the description covers purpose, usage, parameters, and return type. It could be improved by detailing the structure of each flight info string, but overall is quite complete.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description provides detailed explanations for all 11 parameters, including allowed values, defaults, and formats, far exceeding the bare 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 retrieves time-filtered flight information based on user preferences for before/after a certain time, with origin, destination, and departure date. It also explains round-trip handling, distinguishing it from siblings like get_best_flights or get_cheapest_flights.

  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 context on when to use the tool (time-filtered queries) and how to handle round-trip trips by making two one-way calls. However, it does not explicitly mention when not to use it or compare with sibling tools.

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