Server Quality Checklist

Tool Scores

• isochroneB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds value by stating that the tool returns a compact summary (bounding box and reach per direction), which informs the agent about the output format. However, it does not disclose any limitations, permission requirements, or error conditions, which would be expected for a tool with no output schema.

  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 includes an illustrative example. Every sentence is necessary and there is no redundant or extraneous text. It is well-structured for quick understanding.

  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 the tool has 5 parameters (2 required) and no output schema, the description covers the basic functionality and return type but lacks details on output structure, error handling, or behavior for edge cases like invalid coordinates. It does not explain the meaning of 'reach per compass direction' or how to interpret the bounding box. The description is adequate but not comprehensive for a tool with moderate complexity.

  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 60% (center, profile, language have descriptions in schema; minutes and kilometers do not). The description compensates by clarifying that minutes and kilometers are mutually exclusive and by providing the unit context. It also reinforces the overall concept of the tool. For the uncovered parameters, the description adds meaningful guidance 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 tool's purpose: showing reachable area within a time/distance budget. It uses a specific verb ('shows') and resource ('reachable area'), and gives an example query. However, it does not explicitly differentiate from sibling tools like route or route_matrix, which could be clearer given the context of multiple geospatial 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 includes a usage constraint ('Give exactly one of minutes or kilometers') but provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or when to avoid it. Compared to other sibling tools, there is no explicit differentiation or when-not advice.

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

• reverse_geocodeA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the tool is known to be non-destructive. The description adds the behavioral detail that it uses Nominatim (an external service), hinting at potential third-party dependencies. No additional behavioral traits are disclosed (e.g., rate limits, fallback behavior, or response structure), but given the annotations cover safety, the description provides minimal extra value.

  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 short sentence: 'Converts coordinates into the nearest address or place name (Nominatim).' It is front-loaded, contains no filler, and every word adds meaningful context about the action, output, and backend. Ideal conciseness.

  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 3 parameters, no output schema, and is simple conceptually, the description still falls short. It does not explain the return format (e.g., string, object with fields), error cases (e.g., what happens if no address found), or any precision or success criteria. The description is too minimal for an agent to fully understand the tool's behavior without additional knowledge.

  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 3 parameters with only 33% description coverage (language has a description, latitude/longitude do not). The tool description adds no parameter-level details—it does not explain that latitude/longitude should be in decimal degrees (WGS84), nor does it clarify the effect of the optional language parameter. With low schema coverage, the description should compensate, but it fails to do so.

  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 'Converts coordinates into the nearest address or place name (Nominatim)', using a specific verb and resource. It uniquely distinguishes this tool from siblings like 'geocode' (which likely does the reverse) and other tools like 'route' or 'find_nearby_pois' by naming the exact conversion task and the backend service.

  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 vs. alternatives. The tool name and description strongly imply it is for converting coordinates to addresses/place names, which suggests the opposite of the sibling 'geocode', but no direct guidance such as 'Use this when you have coordinates; use geocode for addresses' is provided. The usage is implied but not articulated.

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

• geocodeA
  3.9/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint=true, which is consistent with the description's conversion operation. The description adds value by naming the external provider (OpenStreetMap), listing return fields, and explaining provider behavioral differences (address-specific vs typo-tolerant). It does not reveal rate limits or external dependency caveats, but overall transparency 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.

  Conciseness5/5

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

  The description is exceptionally concise—two sentences with no filler. The first sentence defines purpose and outputs, the second provides key usage differentiation for providers. Every word earns its place, making it easy for an AI agent to quickly parse.

  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 lack of an output schema, the description adequately covers return fields and provider choice. However, it omits guidance for sibling tool differentiation and does not address edge cases (e.g., no results, error handling, rate limits). Still, for a geocoding tool with well-documented parameters, it covers most essential context.

  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% with descriptions for all five parameters. The description adds meaningful context beyond the schema by explaining the provider parameter's behavioral implications (nominatim for addresses, photon for typos). This extra semantic guidance helps agents choose the right provider, raising the score above the baseline of 3.

  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 converts a place name or address into coordinates using OpenStreetMap and specifies the output fields (lat/lon, display label, OSM id). It distinguishes between two providers but does not explicitly differentiate from sibling tools like reverse_geocode, which performs the inverse operation.

  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 guidance on when to use each provider: nominatim for addresses, photon for fuzzy place names. However, it does not offer context on when to use this tool versus its siblings (e.g., reverse_geocode for coordinate-to-address conversion, or find_nearby_pois for proximity searches), leaving the agent to infer tool selection from names alone.

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

• optimize_routeA
  3.9/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already indicates the tool does not modify state, so the description carries a lower burden. The description adds context about the roundtrip behavior, which is useful. However, it doesn't disclose constraints like the max of 12 stops or that stops must be resolvable, which are important for expected behavior beyond the schema.

  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 long, with the first sentence covering the core purpose and the second explaining the roundtrip option. It is front-loaded and efficient, though the second sentence could be split for clarity.

  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 moderate complexity (4 parameters, no output schema, no nested objects), the description covers the optimization problem, return format, and roundtrip behavior. It lacks detail on error cases or place resolution, but the schema handles stop validation. The output is not described but it's a standard optimized route format, so completeness is adequate.

  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 75%, so the description adds value by explaining the roundtrip parameter's effect on the itinerary structure. This goes beyond the schema's boolean description, clarifying that with roundtrip the tour returns to the first stop, and without it the first stop is the start and the last stop is the end.

  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 best order to visit stops (traveling-salesman optimization) and returns an optimized itinerary with total distance and time. This distinguishes it from siblings like route (simple point-to-point routing) and route_matrix (all-pairs distances).

  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 explains the difference between roundtrip and non-roundtrip modes, which helps the agent decide when to use each. However, it does not explicitly say when to use this tool versus alternatives like route_matrix or suggest_meeting_point, leaving the agent to infer based on the purpose statement alone.

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

• route_matrixA
  3.9/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true, so the agent knows the tool is safe for reads. The description adds value by noting that cells are null for nonexistent routes, which is useful behavioral information. However, it does not discuss error behavior (e.g., if an origin/destination cannot be resolved), performance constraints, or rate limits. With good annotation coverage, a 3 is appropriate.

  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 long, front-loads the key output (travel times and distances), and wastes no words. The null-cells detail is a nice addition. It could potentially be even more concise, but it is already very 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 moderately complex tool with 4 parameters and no output schema, the description does well to explain the core matrix behavior and the null-case. It lacks details on return format (e.g., row/column order, units) and error handling, but the annotations handle the safety profile. Given the lack of output schema, a bit more about the return structure would be helpful, but overall 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 50%: two required parameters ('origins', 'destinations', 'profile') have descriptions in the schema, but 'origins' and 'destinations' are only described generically. The description adds a concrete example ('5 hotels against 3 sights') that clarifies the batch comparison use case beyond the schema. However, it does not explain the 'language' parameter or the format of coordinates ('lat,lon') which is already in the schema. The description provides moderate added value on top of 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 uses a specific verb ('computes') and clearly states the core resource ('travel times and distances from every origin to every destination in one call'). It also contrasts with the sibling 'route' tool by emphasizing the all-pairs matrix behavior, and includes the helpful detail that cells are null where no route exists.

  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 describes the ideal usage scenario ('comparing options') and gives a concrete example ('5 hotels against 3 sights'). While it does not provide explicit when-not-to-use guidance or mention alternatives, the context is clear enough. Sibling tools like 'route', 'optimize_route', and 'straight_line_distance' are implicitly distinguished by the matrix emphasis.

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

• map_linkA
  4/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint: true, so the description does not need to reiterate that it is a safe read operation. The description adds the fact that it generates a URL to open in a browser, which is useful behavioral context. However, it does not mention that the link requires network access or that geocoding is involved, which could affect behavior. With annotations covering safety, a score of 3 is appropriate.

  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 with no wasted words. It front-loads the main purpose and then clearly states the two usage patterns. Every sentence adds value, 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?

  Given that there is no output schema, the description does not need to explain the return value (it is clear: a URL). The parameter combinations are well explained, and the tool's simplicity (generating links) is fully captured. The description would benefit from mentioning that the tool does not perform routing or geocoding in real-time, but this is a minor gap.

  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 parameters. The description adds value by clarifying the required parameter combinations ('place' vs 'from' and 'to') and implying that 'profile' and 'language' are optional. However, it does not explain the default behavior for 'profile' (default foot) or 'language' (default en) beyond what the schema provides, so the added value is limited.

  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 'Generates openstreetmap.org links to open in a browser' with specific use cases: 'a marker link for a single place, or a directions link when from and to are given.' This distinguishes it from sibling tools like geocode (which returns coordinates) or route (which computes paths), making the purpose very 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 explicitly states 'Provide either

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

• find_nearby_poisA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so behavioral transparency needs are lower. The description adds the sorting behavior ('sorted by distance') and mentions the default radius (1000m) which goes beyond what annotations provide. 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.

  Conciseness3/5

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

  The description is front-loaded with the core purpose, but the long list of category shortcuts makes it somewhat verbose. While the list is useful, it could be condensed or referenced as a separate resource. The sentence about OSM tags 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?

  For a read-only tool with 100% schema coverage and decent annotations, the description is complete enough. It explains the category parameter thoroughly, hints at output ordering, and points to poi_details for full records. No output schema exists, but the description doesn't need to explain return values per rules.

  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%, so the baseline is 3. The description adds significant value by listing all category shortcuts and explaining how to use OSM tags (key or key=value format with an example), which the schema only describes as a generic string. This additional detail elevates the 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 clearly states the tool finds points of interest near a location, sorted by distance. It distinguishes itself from sibling tools by mentioning poi_details for full records, and the list of category shortcuts provides immediate clarity on what kinds of places can be searched.

  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 tells when to use poi_details instead ('Use poi_details for the full record of one result'), providing good guidance on an alternative. However, it does not address when other sibling tools like reverse_geocode or geocode might be preferred, nor does it explain when not to use this tool.

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

• suggest_meeting_pointA
  4.3/5.0
  Behavior4/5

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

  The annotation readOnlyHint: true indicates the tool is read-only, which the description does not contradict; the suggestion is an analytical result, not a modification. The description discloses the behavioral trait of selecting based on balanced travel times, adding value beyond the annotation by explaining the fairness criterion and the geographic midpoint approach.

  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, efficient sentence that precisely conveys the core functionality. It is front-loaded with the key verb and resource, and every part adds meaning. There is no wasted text; it perfectly balances detail and brevity.

  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 the tool's moderate complexity (5 parameters, 1 required), full schema coverage, and lack of output schema, the description is complete enough. It explains the algorithm (geographic midpoint, balanced travel times) and implies returned value (venue suggestions). The sibling tools and annotations provide additional context, making this description sufficient for effective use.

  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 covers all 5 parameters with descriptions, achieving 100% coverage. The description adds no further parameter-specific details beyond what the schema provides. Since the baseline for high coverage is 3, this is appropriate; the description does not enhance parameter understanding but does not need to.

  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: suggesting a fair meeting point for people starting from different locations. It specifies the verb "suggests", the resource "meeting point", and the unique approach of finding venues around the geographic midpoint with balanced travel times. This distinguishes it from sibling tools like route_matrix or straight_line_distance.

  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 explains when to use the tool: when people start from different locations and need a fair meeting place. It does not explicitly state when not to use it or list alternatives. However, the sibling tools (e.g., route, optimize_route, find_nearby_pois) provide context, and the description effectively positions this tool for balanced midpoint selection.

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

• poi_detailsA
  4.4/5.0
  Behavior4/5

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

  The description confirms read-only behavior ('Fetches'), aligning with the readOnlyHint annotation. It adds value beyond the annotation by detailing what is returned (tags, coordinates, map link), providing richer behavioral context 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?

  Two highly efficient sentences: the first describes the action and output, the second specifies the input format and source. No extraneous words, front-loaded with essential 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?

  For a single-parameter read tool with no output schema, the description adequately covers input source, output contents, and format. Minor gaps exist (e.g., no mention of data limitations or error cases), but the information is sufficient for correct tool selection and 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?

  Schema description coverage is 0%, but the description compensates by explaining the meaning and origin of the osm_id parameter ('Takes an OSM id as returned by find_nearby_pois or geocode') and provides an example format. This adds semantic context that the schema pattern alone does not convey.

  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 uses the specific verb 'Fetches' and clearly identifies the resource as 'the full OpenStreetMap record of one element'. It explicitly lists returned data (tags, coordinates, map link) and distinguishes from siblings by mentioning input sources (find_nearby_pois, geocode), making purpose unmistakable.

  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 states that the tool takes an OSM ID as returned by find_nearby_pois or geocode, providing clear prerequisite guidance. However, it does not explicitly state when not to use the tool (e.g., if you need coordinates from an address, use geocode instead), but the sibling context and the given input source hint adequately.

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

• straight_line_distanceA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the description does not need to re-emphasize safety. The description adds value by noting the tool is 'instant' (performance characteristic) and 'independent of road network' (limitation). This provides helpful behavioral context beyond the annotation.

  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 exceptionally concise: two sentences, no wasted words. It front-loads the core concept ('Great-circle distance') and immediately provides usage differentiation. 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?

  The tool is simple (two required string parameters, no nested objects, no output schema). The description covers the mathematical concept, performance, and when to use alternatives. While it doesn't specify the return format (e.g., units), the overall context is sufficient for an agent to correctly select and invoke the 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?

  Schema description coverage is 100%, with each parameter having a clear description (place name, address, or coordinates). The tool description does not add any additional meaning to the parameters beyond what the schema already provides. Baseline 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 defines the tool's purpose: calculating great-circle ('as the crow flies') distance between two places. It uses a specific verb phrase ('distance between') and distinguishes itself from the sibling route tool by explicitly stating this is not for road distances.

  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 this tool ('instant and independent of any road network') and when not to, with a direct alternative ('use route for real travel distances'). This is exemplary usage direction.

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

• routeA
  4.6/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, which is consistent with the tool. The description adds that waypoints are visited in given order and that data is from OpenStreetMap, providing useful context beyond annotations. A small gap: does not mention whether route is cached or data freshness, but that's minor given readOnlyHint coverage.

  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 sentences front-load the core purpose and provide actionable usage guidance. No wasted words; every sentence adds distinct 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 no output schema and moderate complexity (4 params, 2 required), the description covers purpose, usage, and key behavioral traits. It lacks details on what exactly the output contains (e.g., duration, distance format), but the core is well addressed for selection and 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?

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining that waypoints are traversed in order, that include_steps gives a turn-by-turn summary, and that profile defines the travel mode. This extra context justifies a 4.

  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 calculates real-world travel distance and time between two or more places using specific travel modes on OpenStreetMap data. It distinguishes itself from siblings by naming alternatives like route_matrix and optimize_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 tells when to use this tool vs. alternatives: 'Use route_matrix to compare many pairs, optimize_route to reorder stops.' Also clarifies waypoint ordering and optional turn-by-turn steps.

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