Server Quality Checklist

Tool Scores

• search_multi_cityC
  2.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full behavioral disclosure burden. It only lists parameters and lacks any mention of side effects, read-only nature, rate limits, or result size, which are critical for safe invocation.

  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 short and tightly organized with a single purpose line followed by a bullet-like parameter list. Every sentence contributes essential information, 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?

  Given that an output schema exists, explaining return values is not required. However, the description omits behavioral context and usage guidance that would make the tool fully self-contained. Parameter details cover the basics but lack depth for parameters without enums.

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

  Parameters2/5

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

  Schema description coverage is 0%, yet the description adds only minimal meaning for most parameters. The legs parameter includes an example, and max_stops explains its values, but others (e.g., seat, adults) just repeat the property names without adding allowed values or format details.

  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 opens with 'Search multi-city flights on Google Flights,' which clearly states the tool's verb and resource. While it distinguishes from siblings like search_flights by name, it does not explicitly contrast with other sibling tools.

  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 no guidance on when to use this tool versus alternatives such as search_flights or compare_destinations. It does not mention prerequisites or typical use cases.

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

• compare_destinationsA
  4.2/5.0
  Behavior3/5

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

  The description mentions throttling ('one search per destination (throttled)'), which is a key behavioral trait. However, with no annotations provided, it does not disclose other behaviors such as data freshness, authentication needs, or rate limits beyond throttling.

  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 with a clear one-sentence purpose, followed by a well-structured list of all parameters. No unnecessary words; every sentence adds value.

  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 complexity (11 parameters, output schema present), the description covers the core purpose, parameter details, and a key behavioral note (throttling). It does not explain return value formatting or error handling, but the output schema may cover that. Overall, it is largely complete.

  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 brief explanations for all 11 parameters, compensating for the 0% schema description coverage. Examples include 'Comma-separated IATA destination codes' for to_airports and 'Departure date YYYY-MM-DD' for departure_date. However, some parameters like 'seat' lack allowed values or further detail.

  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 it compares cheapest price to several destinations from same departure airports, specifically mentioning 'where can we go cheaply inspiration searches'. This distinguishes it from siblings like search_flights which are for specific routes.

  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 indicates when to use: for inspiration searches across multiple destinations. It notes 'one search per destination (throttled)', implying it's suitable when throttling is acceptable. However, it does not explicitly state when NOT to use compared to other tools like search_flights or search_flexible_dates.

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

• find_airportA
  4.4/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It explains the query types but does not disclose behavior like case sensitivity, partial match behavior, or what happens on no match. Adequate but could be more detailed.

  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?

  Concise with two clear blocks: purpose/usage and Args. No fluff, but could be slightly more compact.

  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 an output schema exists, description doesn't need to explain return values. It covers essential use and parameters. Lacks mention of error handling but otherwise 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 coverage is 0%, so description compensates fully: explains 'query' (city, name, IATA, country with examples) and 'limit' (max results, default 8). Adds meaning beyond 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's purpose: 'Resolve a city name or airport name into IATA airport codes.' It also explicitly distinguishes it from a sibling by suggesting use before search_flights.

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

  Usage Guidelines5/5

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

  Provides explicit guidance: 'Use this FIRST when you don't know the IATA code to pass to search_flights.' This tells when to use and references an alternative.

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

• search_flexible_datesA
  4.5/5.0
  Behavior4/5

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

  Despite no annotations, the description discloses that it runs one search per candidate date (throttled), a key behavioral trait. It also advises keeping ranges reasonable, implying rate limits. No contradictions.

  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 with a brief intro and structured parameter list. Every sentence adds value, and the purpose is front-loaded. No unnecessary text.

  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 complexity (13 parameters, output schema exists), the description covers all parameters and usage intent. It lacks details on error handling or empty results, but the output schema likely covers return structure.

  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?

  The description provides detailed explanations for all 13 parameters in the 'Args' section, compensating for the 0% schema coverage. It clarifies defaults and special values (e.g., trip_length_days=0 for one-way).

  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 finds the cheapest departure day over a date range, with a specific use case for flexible holiday planning. It distinguishes from siblings like search_flights (fixed dates) and compare_destinations.

  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 advises when to use ('ideal for flexible holiday planning') and warns about performance ('keep ranges reasonable'). It implies not to use for fixed dates, but does not explicitly name alternatives.

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

• find_airports_nearA
  4.6/5.0
  Behavior4/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 sorting by distance, default radius, and limit. It could mention error handling or data freshness, but the core behavior is transparent.

  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, front-loaded with purpose, and includes an organized argument list. Every sentence adds value with no wasted words.

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

  Completeness5/5

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

  Despite no annotations, the description provides sufficient information for a geolocation search tool with 4 parameters. The presence of an output schema (though not detailed here) reduces the need to describe return values.

  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?

  With schema description coverage at 0%, the description fully compensates by explaining each parameter: lat/lon as decimal degrees, radius_km as search radius with default 150, limit as max results with default 8.

  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 verb 'Find' and the resource 'airports near a geographic coordinate', and specifies sorting by distance. It distinguishes itself from sibling tools like find_airport by focusing on coordinate-based search.

  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 says 'Useful for geolocated departure-airport selection', which indicates when to use it. It could be improved by explicitly stating when not to use it or comparing to alternatives, but the context is clear enough.

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

• search_flightsA
  4.7/5.0
  Behavior4/5

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

  Discloses that it tries multiple departure airports by default, accepts IATA codes, and details all parameters. No annotations exist, so description carries full burden. Could mention output structure or pricing limitations, but current coverage is strong.

  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 summary, prerequisite note, and bullet-style Args list. Slightly verbose due to 13 parameters, but each line adds value. No wasted sentences.

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

  Completeness5/5

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

  Covers 13 parameters with defaults, 2 required ones marked, IATA code resolution guidance, and output schema exists to handle return values. Complete for an AI agent to use correctly.

  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 coverage is 0%, but the description defines every parameter with data types, defaults, and usage examples (e.g., 'YYYY-MM-DD', comma-separated IATA codes). Adds critical meaning beyond the schema alone.

  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?

  States 'Search Google Flights for the best prices' with specific verb and resource. Clearly distinguishes from sibling tools (e.g., search_multi_city, search_flexible_dates) by focusing on simple round-trip/one-way search with multiple departure airports.

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

  Usage Guidelines5/5

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

  Explicitly instructs to call find_airport or find_airports_near if only city names are known. Provides default behavior and parameter format guidance. No mention of when not to use, but context about alternatives is sufficient.

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