Server Quality Checklist

Tool Scores

• request_local_coverageB
  3/5.0
  Behavior1/5

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

  The description states 'requesting coverage' and 'remember' which imply a write operation, but the annotations declare readOnlyHint=true (no state change) and idempotentHint=true (read-only). This is a clear contradiction, undermining trust. The descriptions of 'FREE live backend call' add no behavioral clarity beyond the annotations. Score is 1 due to the contradiction.

  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 two sentences, concise and front-loaded with the purpose and usage guidance. The word 'FREE' is slightly redundant but does not significantly detract. It earns high marks for economy, though the single structure could be more formal.

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

  Completeness2/5

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

  Given the tool has 14 optional parameters and no output schema, the description is insufficiently complete. It fails to explain what the request returns, which parameters are necessary for common use cases, or how the backend processes it. Annotations provide some context but the description adds little beyond purpose and use cases.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must compensate by explaining parameters. It only lists examples of what to request in general terms but does not define any of the 14 parameters (e.g., town, location, signal_types). This provides negligible help in understanding how to fill the schema, resulting in a very low score.

  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 explicitly states the verb (requesting coverage) and the resources (town, neighborhood, local ritual, etc.), making the purpose clear. It is distinctly different from sibling tools like plan_flight_route or convert_currency, which are travel planning focused. The informal tone does not obscure the function.

  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 specific scenarios (local vibe, freebie list, etc.) indicating when to use this tool, but it does not explicitly mention when not to use it or compare it to alternative tools. The sibling tools are quite different, so confusion is unlikely, but the lack of explicit exclusions drops the score from 5.

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

• find_transit_optionsB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, covering safety and idempotency. The description adds value by mentioning the tool connects to a 'live paid' service, implying external dependency and cost. However, it does not elaborate on rate limits, authentication, or return behavior, which would be beneficial beyond annotations.

  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, no fluff. The first sentence states the action, the second provides usage guidance. It is front-loaded and every word earns its place.

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

  Completeness2/5

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

  Given the tool has 5 optional parameters with zero schema descriptions and no output schema, the description lacks completeness. It does not explain parameters beyond location/transport type, nor describes what the tool returns. The openWorldHint suggests unknown output structure, but the description offers no further context.

  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?

  The input schema has 5 parameters with 0% description coverage. The description only hints at 'location' and 'transportation_type' as key parameters, ignoring 'trip_style', 'origin', and 'destination'. With nearly no schema descriptions, the description fails to compensate, leaving agent uncertain about parameter semantics.

  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 uses a specific verb 'connect' and identifies the resource as a 'live paid x402 mobility-options service'. It clearly states when to use it: for transit, rail, ferry, trails, bike/scooter options, or a location-filtered short list. While it doesn't explicitly differentiate from sibling tools, the purpose is distinct and clear.

  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 guidance on when to use the tool: 'Use when the traveler wants transit, rail, ferry, trails, bike/scooter options, or a location-filtered short list before planning the rest of the trip.' It does not state when not to use or mention alternatives, 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.

• plan_day_tripB
  3.4/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint, idempotentHint, openWorldHint. The description adds value by disclosing it's a paid x402 service, returns live output or metadata, and covers timing, water, food, transit, weather, and backup. No contradictions with annotations.

  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, approximately 50 words, every sentence provides essential information. Front-loaded with the core purpose, no redundancy.

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

  Completeness2/5

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

  Given 14 parameters, no output schema, and no parameter descriptions, the description is insufficient for correct invocation. It lacks details on parameter formats, how to combine them, and expected return structure. Agents would struggle to fill in parameters appropriately.

  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?

  With 14 parameters and 0% schema description coverage, the description does not explain individual parameter meanings. It only gives high-level hints about content (e.g., timing, water, food), but agents cannot infer how to set origin, destination, interests, etc. from this.

  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 connects to a paid day-trip service for destination/route/origin asks, specifying it's for relaxed day out with various aspects. It distinguishes from siblings like plan_weekend_getaway by focusing on day trips, but lacks explicit differentiation from plan_weather_aware_trip.

  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 context for when to use ('relaxed day out') and mentions output options, but does not explicitly state when not to use or compare with alternatives such as plan_weekend_getaway or plan_weather_aware_trip.

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

• plan_weekend_getawayA
  3.6/5.0
  Behavior5/5

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

  Annotations already indicate readOnly, idempotent, openWorld. Description adds critical behavioral detail: it requires payment via x402 and can return live server output or x402 metadata. This goes beyond the annotations and is valuable for agent decision-making.

  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?

  Three sentences front-load purpose and usage. No fluff, but could be slightly more direct about parameter expectations. Still efficient.

  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 12 parameters, no output schema, and no parameter descriptions, the description covers purpose and usage context but leaves significant gaps about input specifics and expected output format.

  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 coverage is 0% with 12 parameters all optional. The description mentions some concepts (lodging, water/weather, transportation) that loosely map to parameters but provides no explicit semantic meaning or format guidance for any parameter.

  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 connects to a paid weekend-getaway service for short overnight escapes. It distinguishes from siblings like plan_day_trip by specifying it's for weekend getaways. However, the phrasing 'live paid x402 weekend-getaway service' is slightly opaque.

  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 usage context: 'Use when the traveler wants a calmer planning brief with lodging, water/weather, transportation, and backup ideas.' It also mentions payment via x402. But it does not explicitly state when not to use or compare to siblings.

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

• plan_weather_aware_tripA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds that the service is live and paid, and that it provides specific weather awareness (rain, heat, wind, indoor backup). This adds some behavioral context beyond annotations but not extensively; 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?

  Two sentences, front-loaded with the core action and usage scenario. Every sentence is meaningful; no wasted words. The description is appropriately sized for the tool's complexity.

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

  Completeness2/5

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

  Given 8 parameters, no required fields, no output schema, the description is too brief. It does not explain what the output provides, how to use parameters effectively, the meaning of 'x402', or that the service is paid (cost consideration). The tool's completeness is insufficient for reliable agent invocation.

  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%, so the description must compensate. It hints at destination/coordinate pair and weather factors, but it fails to explain how parameters like date, time_window, plan_type, transportation_modes, or max_distance_or_travel_time map to inputs. The brief mention provides minimal guidance.

  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 connects to a specific live paid weather-aware planning service for a destination or coordinate pair. It uses a specific verb ('connect') and resource ('x402 weather-aware planning service'), and it distinguishes from siblings like plan_day_trip or plan_weekend_getaway by focusing on weather awareness.

  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 explicitly says to use the tool when the traveler wants rain, heat, wind, and indoor backup awareness before committing to outdoor time. This provides clear context for when to use it, though it does not mention when not to use it or provide direct alternatives among siblings.

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

• creator_experiencesA
  3.9/5.0
  Behavior4/5

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

  Annotations already indicate read-only (readOnlyHint=true) and idempotent. The description adds key behavioral context: it's a paid service (x402), returns live server output or x402 metadata, and requires client payment capability. This goes beyond annotations but could detail output format more.

  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?

  Description is three sentences, front-loading the main purpose and then usage context. No unnecessary words, but could be slightly more concise by combining 'Connect to...' and 'Use when...' into a single sentence.

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

  Completeness2/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 only vaguely mentions 'live server output or x402 request metadata' without explaining the response structure or content. For a complex planning tool with 9 parameters, this is insufficient for an agent to fully understand the return value semantics.

  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% with clear parameter descriptions. The tool description does not add additional parameter-level details beyond what the schema provides, so 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 it connects to a live paid x402 creator-experience service for travel planning focused on visuals and story. It distinguishes from sibling tools by specifying the target audience (creators, influencers) and the paid nature, which no other sibling tool mentions.

  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?

  Explicitly states 'Use when the traveler cares about visuals, story, timing, food stops, scenic movement, weather-aware backups, or content moments', providing clear context. However, it does not explicitly list when not to use or suggest alternative sibling tools.

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

• check_trip_disruptionsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true (safe read), idempotentHint=true (same result), destructiveHint=false. Description adds important behavioral context: results may be incomplete/delayed/incorrect, informational only, and not emergency services. This exceeds minimal annotation value.

  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 front-loaded with purpose and usage, then adds limitations. It is relatively long but each sentence adds value (use cases, limitations, payment detail). Minor redundancy (e.g., 'Informational only' appears twice in spirit) but overall 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?

  Given no output schema, the description does not explain return values or structure. It covers usage, limitations, and purpose well but lacks output format details. For a tool with 8 parameters and no required fields, more guidance on what the agent receives would improve 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?

  Schema coverage is 100% with descriptions for all 8 parameters. The description provides overall context for the parameters (destination, origin, lat, lon, etc.) but does not add specific meaning beyond what the schema already explains. 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 checks for travel disruptions using a paid service, with specific verb 'Check' and resource 'travel disruptions' (result of x402 Travel Pulse). It distinguishes itself from sibling planning tools like plan_day_trip or find_transit_options by focusing on disruption awareness.

  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 says when to use: before departure or during a trip, with recurring updates on demand. Lists use cases (weather alerts, natural events, water/flood context) and exclusions (not emergency services, not substitute for official instructions). Provides clear alternative contexts.

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

• get_travel_timing_adviceA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare read-only, destructive=false, idempotent. Description adds value: 'FREE', 'no account setup, no external booking link, no booking side effects' which are beyond annotations.

  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: first states purpose and examples, second gives usage and side-effect info. No redundant words, 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?

  No output schema, but description gives reasonable context for a free advice tool. Could mention result format but not missing critical info for selection.

  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 descriptions for both parameters. Description does not add parameter-specific guidance beyond schema, meeting baseline 3.

  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 provides 'practical travel timing advice' with specific examples (booking windows, airport arrival etc.) and distinguishes from sibling tool 'plan_flight_route'.

  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 says 'Use for questions like when to book or how early to arrive' and 'use plan_flight_route when the traveler wants route planning', providing clear when-to-use and alternatives.

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

• plan_flight_routeA
  4.4/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint, idempotentHint, etc. The description adds context: 'Read-only, no account setup, no booking side effects' and mentions response content (metadata and booking links), which adds value beyond annotations.

  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?

  Extremely concise: three sentences with no redundancy. Purpose is front-loaded, followed by usage guidelines, behavioral notes, and a param note. Every sentence earns its place.

  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 purpose, usage, behavior, and param hint. Lacks detailed output structure, but mentions response includes route metadata and booking links. Annotations partially compensate for missing output schema.

  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 baseline is 3. The description repeats some schema info (e.g., return_date optional) but adds no new parameter-level details beyond what the schema provides.

  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 'Plan one flight route between two airports' with a specific verb and resource. It effectively distinguishes from sibling tools like compare_airport_routes, create_booking_link, and get_airport_details.

  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 on when to use ('when a traveler wants a clear starting point') and when not to, naming specific alternative tools for different scenarios. Also clarifies optionality of return_date for one-way trips.

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

• get_airport_detailsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds 'no account setup, no external booking links, no booking side effects' which reinforces read-only nature and provides extra detail, but adds limited new behavioral insight beyond annotations.

  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 concise sentences: first states core purpose, second provides usage guidance. 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?

  For a simple single-parameter lookup tool with comprehensive annotations, the description covers purpose, usage, and behavioral traits adequately. No output schema but not necessary for this type of tool.

  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?

  Only one parameter (code) with 100% schema description coverage. Description does not add meaning beyond the schema's own description; 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?

  Clearly states 'look up details for one airport by IATA code' (verb+resource+identifier) and distinguishes from siblings by referencing plan_flight_route and compare_airport_routes for different use cases.

  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 says 'Use to validate or explain a single airport before route planning' and contrasts with plan_flight_route and compare_airport_routes for trip routes and multiple pairs.

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

• compare_airport_routesA
  4.6/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds context such as 'Read-only, no account setup, no booking side effects' and notes that responses may include commission-eligible external booking links, which aligns with and supplements the annotations without contradiction.

  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 four concise sentences, front-loaded with the main purpose. Each sentence adds unique value: purpose, usage context, behavioral traits, and booking link disclosure. No redundant or extraneous information.

  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 low complexity (1 param, no output schema, rich annotations), the description covers purpose, usage guidelines, and behavioral traits. It mentions booking links but could be more explicit about the comparison output format (e.g., what data is compared). However, with openWorldHint=true, it is reasonably 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 coverage is 100% with the single 'routes' parameter fully described (array of objects with origin/destination). The description adds no extra detail beyond the schema, merely restating 'two or more airport route pairs.' Baseline 3 is appropriate since parameter semantics are fully covered by 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 explicitly states 'Compare two or more airport route pairs side by side,' clearly defining the verb (compare) and resource (airport route pairs). It also distinguishes from sibling tools by naming plan_flight_route for single dated routes and get_airport_details for single airport lookups.

  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?

  The description provides explicit guidance on when to use ('when a traveler is choosing between alternate origins, destinations, or nearby airports') and when not to (by naming alternative tools). It also clarifies that it is read-only with no account setup or booking side effects.

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

• create_booking_linkA
  4.6/5.0
  Behavior5/5

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

  Annotations already set readOnlyHint=true, destructiveHint=false, but description adds 'Read-only, no account setup, no booking completion, and no reservation side effects' plus 'link may be commission-eligible and is disclosed in output' – valuable context beyond annotations.

  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 concise sentences: first states core purpose, second provides usage guidelines and behavioral caveats. No redundant information, 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?

  Description covers purpose, usage, behavioral traits, and hints at output (commission-eligible link). No output schema exists, but the description provides relevant output context. Slight gap: does not specify if link is returned as a URL string or object, but sufficient for selection.

  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% – all parameters have descriptions. Description does not add additional meaning beyond what's already in the schema, so 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?

  Description clearly states 'Create an external booking link for an already chosen route' – specific verb+resource. Distinguishes from sibling planning tools by emphasizing the route must already be selected.

  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?

  Explicit when-to-use ('after route details are known or after compare_airport_routes or plan_flight_route') and when-not-to-use ('use another planning tool first when traveler still needs help choosing'). Also clarifies no booking completion, no reservation side effects.

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

• convert_currencyA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds that it is free, no account setup, no payment, and not a transaction quote, enriching transparency without 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?

  Two sentences, front-loaded with key purpose and usage context, no extraneous 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?

  Given rich annotations and fully described parameters, the description provides all necessary context: it is a free, read-only reference conversion, not a quote. No output schema needed.

  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 description does not need to add parameter details. It adds minimal semantic value beyond stating 'live reference-rate' but does not elaborate on parameters.

  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 performs currency conversion using live reference rates from ForgeMesh. Among siblings, no other tool does currency conversion, so it is well-distinguished.

  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 says when to use (quick spending context before richer guidance) and what not to use for (not a transaction quote), providing clear guidance.

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

• list_travel_categoriesA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that it is 'FREE', 'no account setup, no booking side effects', and 'live', which provides useful behavioral context beyond the annotations, though the core safety profile is already covered.

  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?

  Three concise sentences, front-loaded with key purpose ('FREE live category guide'). Every sentence adds value: purpose, usage guidance, and safety. No redundancy.

  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?

  For a simple zero-parameter tool without output schema, the description completely covers what the tool does, when to use it, and its safety profile. No additional information is needed.

  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 tool has zero parameters with 100% schema coverage (empty schema). Description correctly omits parameter details as none exist. Baseline 4 for no parameters applies.

  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 lists available travel flows/categories, specifying it's a 'FREE live category guide from the ForgeMesh travel-agent backend'. It distinguishes itself from siblings by positioning it as the first call to see available flows before choosing other tools.

  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 says 'Use this first to see the available travel flows and choose the next useful call', and categorizes subsequent tools into free airport/timing/coverage vs paid planning services. This provides clear when-to-use guidance and differentiates from siblings.

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