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

Discloses that the tool returns partial matches not reliable coordinates, specifies the return format, and emphasizes it is a UI tool—all 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.

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

Well-structured with clear sections (WHEN TO USE, DO NOT USE, FOCUS), front-loaded purpose, and no unnecessary sentences.

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

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

Covers usage, return structure, and exclusions comprehensively, despite no output schema. Agent can confidently decide when to invoke.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by emphasizing focus parameters and distinguishing from geocode, but doesn't significantly augment parameter details beyond schema.

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

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

The description clearly states 'Get real-time address suggestions as a user types in an input field' and distinguishes from siblings like 'geocode' by specifying it is a UI tool for live input.

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

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

Explicitly states when to use ('ONLY for powering a live address input field') and when not to use ('DO NOT USE IN AGENTS'), and advises to pass focus.lat/focus.lon when location is available.

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

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

No annotations exist, so the description fully bears the transparency burden. It discloses the return format, field meanings, ordering, status values ('ok' or 'not_found'), caching benefits, plan limits, and country accuracy tip. No behavioral surprises remain.

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

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

The description is compact but rich, using clear section headings (PERFORMANCE, CACHING, PLAN LIMITS, COUNTRIES, USE FOR). Every sentence adds unique value. No redundant or filler language.

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

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

The tool has 2 parameters, no output schema, and moderate complexity. The description covers inputs, output structure, performance, caching, plan constraints, accuracy tips, and appropriate use cases. It fully equips the agent to use the tool correctly and efficiently.

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

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

Schema coverage is 100%, and the description adds crucial semantics: addresses parameter explicitly warns 'Deduplicate before sending' and refers to plan limits; countries parameter provides ISO examples and usage guidance ('Pass countries when all addresses are in the same country'). This goes well beyond the bare schema.

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

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

The description clearly states 'Geocode multiple addresses in a single API request.' It specifically contrasts with the sibling 'geocode' (single address) and 'batch_reverse_geocode' (reverse geocoding), making the tool's exclusive purpose unambiguous.

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

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

Provides explicit guidance: 'Always use batch_geocode for 2+ addresses. Never loop geocode calls — batch is far faster and uses fewer API credits.' Also lists specific use cases ('Importing customer lists, processing address CSV files, bulk ETL pipelines'), leaving no doubt about when to invoke this tool.

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

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

Discloses that results are in the same order as input, which is important behavioral information. No annotations are provided, so the description bears full burden. It could mention error handling or rate limits, but the disclosed behavior is sufficient for most use cases.

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

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

Extremely concise: three sentences, a sample return line, and use cases. No unnecessary words. Front-loaded with action and context.

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

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

For a simple tool with one parameter and no output schema, the description provides complete context: purpose, usage guidelines, return format, and examples. The sibling tools are clearly differentiated.

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

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

Schema coverage is 100%, so the description adds no extra meaning beyond what the schema already provides. The description repeats the structure but does not clarify edge cases or formatting requirements.

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

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

The description clearly states the tool performs reverse geocoding for multiple coordinates in a single API request. It distinguishes from the sibling tool 'reverse_geocode' by explicitly noting its batch capability, and from 'batch_geocode' by specifying reverse geocoding.

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

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

Provides explicit guidance: 'Always use batch_reverse_geocode for 2+ coordinates. Never loop reverse_geocode calls.' Also lists specific use cases (enriching GPS exports, converting datasets).

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

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

Discloses resolution limitation (~30m global, higher in some regions) and return format. No annotations, so description carries the burden well.

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

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

Compact three-paragraph structure with front-loaded purpose. No fluff; every sentence adds value.

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

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

Simple tool with 2 params and no output schema. Description covers purpose, usage, return, and a key limitation. Adequately complete.

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

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

Schema describes both params (lat, lon) with ranges (100% coverage). Description adds no extra parameter detail, so baseline 3 is appropriate.

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

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

States 'Get the elevation (altitude above sea level in metres) for a geographic coordinate' – a specific verb and resource. Clearly distinguishes from sibling tools (geocoding, routing, maps).

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

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

Explicit 'WHEN TO USE' section with concrete use cases (hiking, drone routing, flood risk). Lacks explicit when-not-to-use or alternatives, but context is clear.

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

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

With no annotations, the description fully discloses behavior: return format, confidence interpretation, caching policy, and country bias. No hidden side effects; geocoding is read-only.

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

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

Well-structured with clear sections. Every sentence adds value; no waste. Front-loaded with the core purpose and return format.

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

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

Despite no output schema, the description covers return format, confidence interpretation, caching, and bias. For a geocoding tool, this is comprehensive and actionable.

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

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

Schema coverage is 100% with good descriptions. The description adds usage context (e.g., 'Always pass countries when the user's region is known') and explains parameter roles, but schema already covers basic semantics.

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

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

The description clearly states 'Convert an address or place name into WGS84 coordinates (lat/lon).' It distinguishes from reverse_geocode and autocomplete, providing a precise verb-resource pairing.

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

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

Explicit 'WHEN TO USE' and 'DO NOT USE' sections with references to sibling tools. Additional guidance on confidence thresholds, caching, and country bias provides clear decision-support.

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

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

With no annotations, the description carries the full burden. It discloses authentication methods (X-API-Key header for server-side, &api_key for URL), the return format (url, auth_note, html_example), and that no JavaScript is needed. It does not mention any side effects or permissions, but as a URL generation tool, it is inherently non-destructive and read-only.

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

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

The description is very concise and well-structured. It has clear sections: purpose, return format, use cases, zoom guide, and authentication instructions. Each sentence adds value without redundancy.

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

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

Given the tool has 6 parameters (4 required), no output schema, no annotations, and sibling tools that are distinct, the description covers most aspects: purpose, usage context, authentication, and zoom guidance. It could be more complete by explicitly mentioning that the map is in PNG format and that the URL is for the Mapsi API, but overall it is sufficient for an agent to use correctly.

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

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

Schema description coverage is 100%, baseline 3. The description adds a detailed zoom guide that explains how zoom levels correspond to map scales (e.g., 14-16 street level), which goes beyond the schema's brief description. For other parameters like width, height, and API key, the description does not add extra meaning beyond the schema, but the zoom guide is a significant addition.

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

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

The description clearly states the tool builds a URL for a static PNG map image centered on a location. It provides the return format and distinguishes itself from siblings like geocode, route, and map_match by focusing on static map URL generation. The verb 'build' and resource 'URL for a static PNG map image' are specific and unambiguous.

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

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

The description explicitly lists use cases: email templates, PDF reports, social sharing previews, server-side image generation, with note that no JavaScript is needed. The zoom guide provides contextual advice on zoom levels for different map scales. However, it does not mention when not to use this tool or explicitly contrast with sibling tools like get_tile_style_url.

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

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

Discloses auth mechanism (key in URL, not header), return structure, and style options. No annotations provided, making description the sole source. Covers read-only nature implicitly.

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

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

Well-organized with sections for returns, auth, styles, and usage. Every sentence adds value without redundancies.

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

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

Complete given no output schema: explains return fields, all style variants, and auth. No significant gaps.

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

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

Adds context beyond schema: explains api_key embedding as ?key= param and describes each style briefly. Schema coverage is 100%, but description enhances understanding.

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

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

Clearly states the tool retrieves a MapLibre GL style URL for Mapsi tiles, listing return fields and style options. Distinct from sibling get_static_map_url.

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

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

Explicitly states use case 'for initializing MapLibre GL JS, React Map GL' and lists styles. Lacks direct when-not-to-use guidance but is specific enough.

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

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

No annotations are provided, so the description fully bears the burden. It discloses the return fields (h3_index, resolution, center_lat, center_lon) and behavior (simple conversion, no adjacent cell derivation). It could mention idempotency or statelessness, but the current detail is adequate for safe agent invocation.

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

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

The description is efficiently structured: purpose, return values, resolution table, and usage notes in three concise paragraphs. Every sentence adds value, and key information is front-loaded. No redundancy or filler.

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

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

Given no output schema, the description explicitly lists return fields. It covers purpose, all parameters (with resolution guidance), usage scenarios, and a behavioral constraint (no manual cell derivation). This is complete for a straightforward coordinate conversion tool, leaving no ambiguity for the agent.

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

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

Schema coverage is 100% with detailed field descriptions. The description adds significant value beyond the schema by providing a resolution guide with area estimates (e.g., resolution 7 for neighbourhood-level) and practical usage notes for bulk indexing, which helps the agent choose appropriate resolution values.

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

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

The description begins with a clear verb-resource statement: 'Convert a coordinate to an H3 hexagonal grid cell index at a given resolution.' This explicitly distinguishes it from sibling geocoding, routing, and mapping tools, which have different purposes.

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

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

The 'USE FOR' section lists common applications (spatial aggregation, heat maps, geospatial indexing, joining datasets), and the NOTE advises against manually deriving adjacent cells. While it does not explicitly state when not to use, the guidance is sufficient given no direct sibling tool with similar functionality.

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

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

With no annotations provided, the description fully discloses the return format ('GeoJSON FeatureCollection with one Polygon per contour') and explains how to use the output with mapping libraries. It also notes constraints like max values and mutual exclusivity, ensuring transparent behavior.

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

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

The description is well-structured with sections (purpose, output, contours, use cases) and uses bold for emphasis. Every sentence is informative without redundancy, achieving conciseness and clarity.

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

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

Given the tool's complexity (mutual exclusivity, multiple parameter types, GeoJSON output), the description covers all necessary information: purpose, parameter rules, output format, and integration examples. No output schema exists, but the description compensates adequately.

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

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

Although input schema coverage is 100%, the description adds significant value by reinforcing mutual exclusivity, providing example values, stating the default mode ('auto'), and explaining the output format. This goes beyond the schema's bare definitions.

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

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

The description clearly states 'Generate a reachability polygon' and specifies the geographic area reachable from a point within a given time or distance. It distinguishes itself from sibling tools by mentioning specific use cases like delivery zone visualization and service area planning.

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

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 (e.g., 'show restaurants within 15 min walk') and includes clear instructions for the contours parameters: 'you must provide EITHER contours_minutes OR contours_meters, not both and not neither', with examples and constraints.

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

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

Despite no annotations, the description discloses key behaviors: output structure (matched_points, confidence, geometry), coordinate ordering criticality, minimum points, and recommended sampling rate. It does not cover side effects or authentication needs, but the disclosed details are substantial for a map-matching tool.

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

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

The description is well-structured: purpose first, then return details, then a clearly marked coordinate warning, followed by requirements and use cases. It is slightly verbose but remains focused and easy to parse. All sections serve a function.

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

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

Given the absence of an output schema, the description provides the full return shape and useful context about coordinate ordering and usage. It could clarify the 'confidence' scale or mode effects, but overall it covers the essential aspects for correct invocation.

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

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

With 100% schema coverage, the schema already documents both parameters. The description adds value by emphasizing the coordinate order with a critical warning, examples, and explanations of correct vs. wrong usage. For the 'mode' parameter, it does not add beyond the schema, but the coordinates enrichment justifies a score above baseline.

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

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

The opening sentence clearly states the tool's function: 'Snap a raw GPS trace to the road network to correct GPS drift and determine the actual route taken.' This provides a specific verb and resource, effectively differentiating from siblings like nearest_road (which handles single points) or route (which computes optimal paths).

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

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

The description includes 'USE FOR: Fleet tracking post-processing, trip analysis, mileage calculation, delivery verification' and gives minimum point requirements, but does not explicitly compare to sibling tools or state when not to use. Usage context is implied rather than directly contrasted with alternatives.

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

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

With no annotations provided, the description carries full burden. It discloses the return format (sources, targets, durations, distances), explains the matrix indexing, and specifies limits and performance benefits. However, it does not explicitly state whether the operation is read-only or if any side effects occur, which is a minor gap.

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

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

The description is concise and well-structured: a clear opening statement, followed by output format, performance advice, limits, and use cases. Every sentence is informative without redundancy.

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

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

Given the tool's complexity (4 parameters, no output schema), the description provides a complete picture: how to call it, what the output looks like, how to interpret indices, and why to prefer it over alternatives. No critical information is missing.

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

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

Schema coverage is 100%, and parameters are well-documented in the schema. The description adds value by explaining how to interpret the output arrays (durations[i][j] = travel time from origin i to destination j) and emphasizes defaults (auto, km). This enhances the agent's understanding beyond the schema.

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

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

The description clearly states the verb and resource: 'Calculate travel times and distances between multiple origins and destinations in a single request.' It differentiates from the sibling 'route' tool by explicitly stating to prefer matrix over calling route in a loop, establishing its unique purpose for multi-pair computations.

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

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

The description provides explicit when-to-use guidance: 'Always prefer matrix over calling route in a loop' and 'One matrix call replaces N×M individual route calls.' It also lists specific use cases (nearest-store finder, multi-stop delivery planning) and limits (50x50), enabling clear decision-making.

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

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

No annotations are provided, so the description carries the full burden. It transparently describes the output fields (lat, lon, distance_m, road_name) and the snapping behavior. It could mention error cases but overall is clear.

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

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

The description is concise, front-loads the purpose, then provides output format and usage guidelines. Every sentence adds value with no redundancy.

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

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

Given the tool has 2 simple parameters and no output schema, the description compensates by listing return fields and providing recovery steps. It is complete for an agent to use correctly.

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

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 context by explaining that the lat/lon are used as an input coordinate to snap to the nearest road, which adds value beyond the schema.

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

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

The description clearly states 'Find the nearest point on the road network to a given coordinate,' specifying the verb (find), resource (nearest point on road network), and input (coordinate). It distinguishes from siblings like geocode and route.

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

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

The description explicitly provides 'WHEN TO USE' and 'RECOVERY' guidance, stating to snap waypoints before route and to use if route fails. This offers clear context and alternative usage.

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

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

With no annotations, the description carries full burden. It discloses a key side-effect: geocoding returns lat/lon. However, it does not mention any potential destructive actions, authorization needs, rate limits, or data persistence. Still, the main behavioral impact is well communicated.

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

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

The description is very concise, using three short paragraphs: purpose and return format, when to use, and when not to use. Every sentence adds value with no redundancy or filler.

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

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

Given the lack of output schema and annotations, the description covers the essential: purpose, return fields, usage guidance, and side-effect. It could mention limitations (e.g., supported address formats) but is still quite complete for a simple tool.

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

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

Schema coverage is 100% with both parameters described (q with examples, countries with purpose). The description adds no additional semantic context for the parameters beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

Clearly states it normalizes and standardizes messy address strings, and explicitly distinguishes from geocode by stating 'DO NOT USE if you just need coordinates'. The verb 'normalize' is specific and the resource is address data.

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

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

Provides explicit 'WHEN TO USE' scenarios (cleaning data, deduplicating CRM, standardizing for batch) and a clear 'DO NOT USE' alternative (geocode for coordinates). Also notes that geocoding is a side-effect, guiding appropriate usage.

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

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

With no annotations, the description carries full burden. It discloses return format, default/max radius, result ordering, and query hints. Lacks mention of authentication or rate limits but is transparent enough for a search tool.

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

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

Well-structured with clear sections (QUERY, RADIUS, RESULT ORDER, USE FOR, DO NOT USE). Every sentence is informative with no redundancy.

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

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

Given 6 parameters and no output schema, the description covers all key aspects: purpose, parameters, expected output format, and usage boundaries. Examples further enhance completeness.

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

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

Schema description coverage is 100%, and the description adds value beyond the schema: default radius with usage context (rural vs urban), max radius, query examples, and country format example.

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

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

The description clearly states the tool's purpose: 'Find points of interest, businesses, and landmarks near a geographic coordinate.' It specifies the return format and distinguishes from siblings like geocode and point_in_polygon in the DO NOT USE section.

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

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

Explicit usage guidance: 'USE FOR' lists common tasks, 'DO NOT USE' gives alternatives (geocode, point_in_polygon). Also provides tips for query and radius adjustments.

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

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

With no annotations, the description carries the full burden. It discloses the return structure (object with fields like country, region) and notes that not all levels are present, adding value beyond the schema. However, it does not explicitly state this is a read-only operation, though it's implied.

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

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

The description is well-structured and concise: a clear first sentence, a list of return fields, notes on variability, and grouped use cases. Every sentence adds value.

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

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

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description fully covers purpose, return format, usage scenarios, and exclusions, making it complete for an AI agent.

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

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

Schema coverage is 100% with lat/lon ranges fully documented. The description does not add new parameter-level semantics 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.

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

The description clearly states 'Get the full administrative hierarchy for a geographic coordinate,' which is a specific verb+resource. It explicitly distinguishes from the sibling tool reverse_geocode by advising against using it for street addresses.

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

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

The description provides explicit 'USE FOR' and 'DO NOT USE' sections, listing concrete scenarios like territory assignment and tax region detection, and directing users to reverse_geocode for street addresses.

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

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

With no annotations provided, the description carries the full burden. It discloses that results may be approximate for remote areas. This adds valuable behavioral context beyond the schema. However, it does not mention other traits like rate limits or error handling.

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

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

The description is front-loaded with purpose, then lists returns, usage guidelines, granularity, and a note. Every sentence is necessary and well-organized, with no wasted words.

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

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

Given the complexity (4 parameters, 2 required, no output schema), the description covers return fields, use cases, and granularity options. It is complete enough for an agent to understand when and how to use the tool effectively.

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

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

The schema covers 100% of parameters, so the baseline is 3. The description adds value by explaining the layers parameter's granularity (address, locality, street) and listing the return fields (formatted_address, street, housenumber, etc.), which are not in the input schema.

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

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

The description clearly states 'Convert geographic coordinates (lat/lon) into a human-readable address' with a specific verb and resource. It also lists the return fields. However, it does not explicitly distinguish from sibling tools like geocode or batch_reverse_geocode.

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

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

The description includes explicit WHEN TO USE and DO NOT USE sections, providing clear context for when this tool is appropriate (when you have coordinates) and when to avoid it (when you already have a formatted_address). It also advises on granularity options.

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

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

No annotations are provided, but the description fully discloses the return format (distance_km, duration_sec, legs, steps, geometry), explains that duration_sec is under normal conditions without live traffic, and clarifies waypoint order and travel mode effects (e.g., truck restrictions).

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

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

The description is concise and well-structured: a single sentence for purpose, structured return format, and bullet-point notes for key aspects like waypoint order and travel modes. Every sentence provides essential information without redundancy.

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

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

Given the tool's complexity (routing with waypoints, modes, units), the description covers critical behavioral aspects (order, modes, ETA, multi-stop). Missing details like optimization criteria (time vs. distance) and lack of output schema slightly reduce completeness.

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

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

The input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds value by reinforcing waypoint order, explaining travel mode enum semantics (e.g., truck applies restrictions), and noting multi-stop optimization, earning a 4.

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

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

The description clearly states 'Get turn-by-turn directions between two or more waypoints,' specifying a unique verb and resource. It distinguishes the tool from siblings like 'matrix' and 'isochrone' by focusing on detailed route generation.

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

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

The description provides clear usage context: waypoint ordering, travel modes, and ETA limitations (no live traffic). However, it does not explicitly state when not to use this tool (e.g., for simple distance queries where 'matrix' might be better), leaving room for improvement.

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

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

No annotations provided, so description carries full burden. It does not disclose any behavioral traits such as data source, accuracy, error handling, or rate limits. Only return format is mentioned, which is minimal.

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

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

Very concise: three sentences covering purpose, return format, examples, and usage context. No redundant information; each sentence adds value.

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

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

For a simple tool with two params, the description explains return fields and gives usage examples. Could mention error handling, but schema already constrains ranges. Fairly complete.

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

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

Schema covers 100% of parameters with descriptions including ranges. Description does not add new semantic meaning beyond what schema provides, so baseline score of 3 is appropriate.

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

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

Description clearly states 'Get the IANA timezone for a geographic coordinate' with a specific verb and resource. It also lists the return fields and provides examples of IANA names, distinguishing it from sibling geospatial tools like geocode or elevation.

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

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

Explicitly provides use cases in 'WHEN TO USE' section (scheduling ETAs, time conversion, detecting timezone). No explicit 'when not to use' but given sibling tools are different, it's clear this is for timezone lookup only.

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