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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds valuable behavioral context: it auto-detects input format, returns a comprehensive set of notations, and accepts place names for geocoding. These are traits not evident from annotations or schema alone.

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: it opens with the core purpose, explains the auto-detection and output scope in the second sentence, and then delivers usage guidance concisely. Every sentence earns its place, 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's complexity (multi-format conversion), the presence of an output schema, and annotations covering safety, the description is sufficiently complete. It explains the auto-detection, lists output formats, includes geocoding capability, and routes to alternatives, leaving nothing an agent needs to call it 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% with detailed parameter descriptions (e.g., grid_digits precision mapping, location examples). The description adds no additional parameter-specific meaning beyond the schema, so the baseline 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?

The description clearly states the tool converts a position between all common coordinate notations, with a specific verb and resource. It distinguishes itself from siblings by naming coord_transform_crs for datum/projection conversion and coord_describe for validation, making its unique role obvious.

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 when-to-use and when-not-to-use guidance, naming two alternatives (coord_transform_crs and coord_describe) with clear conditions for each. This fully removes ambiguity about tool selection.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description doesn't need to repeat that. It adds value by explaining that the tool normalizes input and returns an explanation for invalid input, which is useful context beyond the safety hints. However, it doesn't describe the exact output structure or the precision levels returned, but given annotations cover safety, a 3 is reasonable.

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, starting with the primary purpose, then explaining the normalization and precision implications, and ending with error behavior. Each sentence serves a purpose, and the use of a concrete example (4-digit grid reference, 5-char geohash) makes it informative without being verbose.

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?

With an output schema present, the description doesn't need to detail return values. It covers the tool's validation purpose, normalization behavior, and precision implications, which is sufficient for a single-parameter tool. A minor gap is not describing the exact output format, but that's covered by the output schema.

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% (the only parameter 'value' is described as 'The coordinate string to inspect.'). The description adds context about what the tool does with the value, but doesn't add new parameter-specific semantics beyond what the schema already provides. Hence baseline 3.

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 it checks if a string is a valid coordinate and reports its precision. It specifies the resource (coordinate strings) and the operation (validate, normalize, state precision), distinguishing it from sibling tools that convert, transform, or measure.

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?

It explicitly mentions it is safe to use for validating user input before acting on it, and explains error behavior (returns is_valid=false rather than failing). This gives clear guidance on when to use it versus other tools, though it doesn't name alternatives explicitly, the context is clear enough.

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

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

The description adds substantial behavioral context beyond the annotations: it discloses that the tool reports the exact PROJ transformation and accuracy, explains what ballpark=true means in practical error terms, and reveals that missing_grids identifies unavailable grid files. It also documents the always-x/y axis-order convention, which is valuable operational information.

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 dense but every sentence earns its place: purpose, supported systems, accuracy caveats, and axis-order rule. It is front-loaded with the primary action and avoids filler or redundant restatement of the schema.

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 read-only, idempotent transform tool with an output schema, the description covers all important operational concerns: supported CRS scope, transformation accuracy, missing-grid behavior, and axis order. Nothing critical appears missing for an agent to select and invoke the tool 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%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that inputs and outputs are always x/easting first and y/northing second regardless of CRS axis order, which directly informs how x and y parameters must be supplied. This lifts it above the 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 description clearly states the core action with a specific verb and resource: 'Transform coordinates between any two coordinate reference systems.' It names supported CRS families and 'any other EPSG-registered CRS,' but it does not explicitly distinguish this tool from the sibling coord_convert, so it stops short of full sibling differentiation.

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 gives clear context for when to use this tool: whenever coordinates need transforming between CRSs, with national grids, Web Mercator, and any EPSG-registered system named as examples. It does not provide explicit exclusions or name alternatives for when not to use it, so it earns a 4 rather than a 5.

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?

Beyond the annotations, the description reveals meaningful behavior: automatic input detection, validation of results, and specific error reporting (self-intersections, out-of-range coordinates, removed RFC 7946 'crs' member). It also notes offline execution, which is useful operational context not present in annotations.

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, starts with the core conversion action, and every sentence carries distinct value: format list, validation behavior, and real-world use cases. No filler or redundant restatement.

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 three-parameter tool with full schema coverage and an output schema present, the description covers input formats, output format flexibility, validation behavior, offline operation, and typical usage scenarios. Nothing essential for correct invocation 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 description coverage is 100%, so the schema already documents data, to_format, and from_format thoroughly. The description adds general context about auto-detection and validation, but does not add parameter-level detail beyond what the schema already provides.

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 uses a specific verb ('Convert') with a clear resource ('geospatial data') and enumerates the supported formats, which immediately distinguishes this tool from coordinate-focused siblings like coord_convert and geometry-operation tools like geom_transform. The scope is precise and actionable.

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 gives clear applicable scenarios with concrete examples ('a customer sends KML, the routing engine wants an encoded polyline'), making it easy to know when to call this tool. It does not explicitly name sibling tools to avoid, but the format-conversion focus is distinct enough among the listed siblings.

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?

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds context about the free tier licensing and the need to set OPEN_METEO_API_KEY and OPEN_METEO_BASE_URL for commercial use, which goes beyond the annotations. It also notes no API key is needed for the free tier, adding useful behavioral context.

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 five sentences, with the purpose stated upfront. It is concise and each sentence adds value, though it could be slightly trimmed without losing meaning.

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 weather tool with a full output schema and comprehensive annotations, the description is complete. It covers the API provider, licensing, use cases, and data returned. No critical missing information is apparent.

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 already provides descriptions for all three parameters (location, days, include_hourly) with 100% coverage, so the description adds no additional parameter guidance. The baseline of 3 is appropriate as the schema carries the semantic load.

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 action (Get) and resource (current weather and multi-day forecast) for a location. It lists the specific data fields returned (temperature, precipitation, wind, cloud cover, humidity, visibility) and names the provider (Open-Meteo), distinguishing it from sibling tools like sun_moon or terrain_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?

The description provides explicit use cases such as delivery scheduling, field work, construction, outdoor events, agricultural spray windows, and travel decisions. However, it does not mention when not to use the tool or name alternative tools, so it lacks explicit exclusions.

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?

Beyond the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description discloses concrete outputs: the exact enable command, which optional API keys are configured, and where the response cache lives. This adds meaningful behavioral context that the annotations do not capture, fully informing the agent of what to expect from the call.

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 three short paragraphs, front-loaded with the core purpose, then usage guidance, then additional output details. Every sentence earns its place, with no filler or redundancy. The structure guides the reader from what → when → what else, which is optimal for agent comprehension.

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 zero-parameter interface, safe annotations, and existence of an output schema, the description is fully sufficient. It explains the purpose, the trigger condition, and the expected outputs, leaving nothing an agent needs to decide whether and when to call it. No gaps are apparent.

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 tool takes zero parameters, and the schema coverage is 100% (vacuously). Per the rubric, the baseline is 4 for zero-parameter tools. The description does not need to elaborate on parameters, and it doesn't; it focuses on purpose and output, which 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 opens with a precise verb and resource: 'List which geospatial toolsets are enabled and what else is available.' This clearly distinguishes it from the sibling geospatial tools, which perform specific operations; this tool is a meta-capability probe. The purpose is unambiguous and immediately actionable.

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?

It explicitly tells the agent when to invoke it: 'Call this when a capability seems to be missing, before telling the user something is impossible.' It also explains the rationale and what the tool returns (the exact command to enable a toolset), leaving no doubt about its appropriate use. No alternative tools are needed, but the condition is specific.

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?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond that: the use of Karney's algorithm on WGS84, millimetre accuracy, near-antipodal robustness, and ellipsoidal area computation. It also clarifies that results are straight-line, which is a key behavioral trait not captured in annotations.

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: it front-loads the purpose, then provides algorithm details, and ends with a usage alternative. Every sentence adds value, with no redundancy or fluff.

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 a rich output schema (as indicated by 'Has output schema: true'), so the description need not explain return values. It covers the core computational behavior, accuracy, and the key distinction from route_directions, which is essential for correct usage. The parameter schema covers parameter semantics, so nothing critical 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 description coverage is 100%, so the schema already documents all three parameters (origin, geojson, destination). The description does not add parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate. It mentions area and distance but does not tie them to parameters beyond what the schema already does.

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 states a specific verb ('measure') and resource ('geodesic distance and bearing between points, or a geometry's area'), which clearly distinguishes it from sibling tools like route_directions. It also explicitly notes this is straight-line distance, making the tool's role 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 tells the agent when to use this tool vs. an alternative: 'For travel distance and time along real roads, use route_directions instead.' This is a clear exclusionary condition, and it also implies the intended use for geodesic/straight-line measurements.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds a valuable behavioral detail: invalid geometries are auto-repaired before the operation, which is beyond the annotations and helps set expectations. It also clarifies the output is the resulting area, which is useful. 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.

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

The description is three sentences: the core function is front-loaded, followed by illustrative use cases, then a note on auto-repair. Every sentence earns its place with no redundancy. It is concise and well-structured.

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 an output schema (per context signals), so return values are covered externally. The description covers purpose, use cases, and an important behavioral nuance (auto-repair). It does not explicitly mention symmetric_difference, but the schema lists it, so the description is complete enough for a 3-parameter tool with an output schema.

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% per the context signals, so the schema already documents all three parameters with descriptions and enums. The description does not add parameter-specific details beyond what the schema provides, but it does mention the operation types in examples. Since the schema is thorough, the 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 explicitly states 'Combine two geometries with a set operation, reporting the resulting area.' It provides concrete examples (intersection, union, difference) and clearly differentiates this overlay tool from siblings like geom_measure or geom_relate. The verb+resource+outcome 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?

It gives real-world scenarios (delivery zone vs. flood extent, service area footprints, uncovered territory) that illustrate when to use this tool. However, it does not explicitly mention when NOT to use it or name alternative tools, so it falls short of a 5 but is still clear on context.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral value by disclosing that the tool returns multiple relationship types plus geodesic distance and nearest points in one call, which is beyond what annotations provide. It doesn't mention error behavior or edge cases, but the annotations carry the main safety burden.

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?

Three sentences with zero waste. The core purpose is front-loaded, the output scope is summarized in the second sentence, and concrete use cases close it out. Every sentence earns its place.

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 description is complete for a read-only relationship-testing tool with a rich output schema. It covers what the tool does, what it returns, and when to use it. The only minor gap is not mentioning whether the input geometries must be in the same CRS or how invalid geometries are handled, but the output schema and annotations cover most operational needs.

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%, so the schema already documents both parameters as GeoJSON or WKT. The description adds the semantic context that these are two geometries being tested for relationships, but doesn't add format details beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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 names a specific verb ('test') and resource ('spatial relationship between two geometries'), then enumerates the exact relationship types (point-in-polygon, overlap, containment, adjacency) plus distance and nearest-point outputs. This clearly distinguishes it from sibling tools like geom_measure (measurement) and geom_overlay (spatial operations).

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: geofence checks, territory assignment, and proximity screening. It also implicitly distinguishes from siblings by focusing on relationship testing rather than coordinate conversion, transformation, or measurement. The 'Use this for' phrasing gives concrete when-to-use guidance.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: distances are true ground metres, buffering uses an azimuthal equidistant projection (avoiding degree-based distortion), and concave vs convex hulls have distinct use cases. This goes beyond what annotations provide.

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 a one-sentence summary, then provides necessary details on projection and hull selection. The second paragraph is somewhat lengthy but explains a common pitfall (degree-based distortion) that saves real trouble. Overall it is tight and purposeful, with no 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?

The tool supports seven operations, but the description only elaborates on buffer and hulls. Centroid, simplify, repair, and bbox are not given any specific behavioral or usage context. Since an output schema exists, return values are covered, but some operations remain under-described for an AI agent to choose among them confidently.

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%, so the baseline is 3. The description adds meaningful nuance beyond the schema: it explains that distances are true ground metres, that the ratio scale is steeply non-linear, and that distance_m is applied in metres for both buffer and simplify. This enhances understanding of how parameters behave in practice.

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 first sentence 'Reshape a geometry: buffer, simplify, hull, centroid, repair or bounding box' clearly states a specific verb (reshape) and the resource (geometry), and lists the supported operations. It does not explicitly differentiate from sibling tools like geom_measure or geom_overlay, but the operation list makes the tool's scope evident and distinct enough.

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 gives implicit usage guidance by naming the operations, but it never explicitly says 'use this tool when you need X, use geom_measure when you need Y'. There is useful internal guidance on choosing concave_hull vs convex_hull, but no direct comparison to sibling tools or exclusions, so it remains at an implied level.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds valuable context about the backend (Nominatim vs Photon) and why the fuzzy path exists, going beyond what annotations convey. It does not contradict any annotations.

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 three short paragraphs, each earning its place: the first states the core purpose, the second explains backend routing and policy, and the third directs to sibling tools. It is front-loaded and free of fluff.

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 moderate complexity (4 params, output schema present, annotations covering safety), the description fully covers what an agent needs: the exact input kind, the fuzzy distinction, the policy constraint, and clear alternatives. No missing operational details.

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 baseline is 3. The description's mention of the fuzzy parameter largely repeats what the schema already says ('Set this for partial, misspelled or as-you-type input'), and it does not add extra meaning to limit, country_codes, or query beyond their schema descriptions.

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 opens with a clear, specific statement of what the tool does: 'Find the coordinates of an address, place name or landmark.' It explicitly distinguishes itself from place_reverse (reverse geocoding) and place_search (categorical search), leaving no ambiguity about its scope.

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 gives explicit when-to-use guidance, including when to set fuzzy=true for misspelled/partial input and routes to place_reverse and place_search for other use cases. It also mentions Nominatim's policy restriction, which directly informs tool selection.

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?

Annotations already cover readOnly, openWorld, idempotent, and destructive hints, so the safety profile is known. The description adds valuable behavioral context by explaining how the zoom parameter changes the granularity of results (building to country), which is not captured by the annotations alone. This goes beyond the minimal requirement and gives the agent a clear mental model of output variation.

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, with the primary purpose stated in the first sentence, followed by a brief explanation of its relationship to place_geocode and concrete use cases. No unnecessary words; every sentence adds value. The zoom tip is placed at the end, effectively closing with actionable guidance.

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 presence of an output schema (has_output_schema=true) and comprehensive annotations, the description covers all necessary aspects for correct invocation: purpose, use cases, inverse relationship, and zoom behavior. No missing prerequisites or error conditions are critical for an agent to use this tool safely and 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 both parameters are documented. The description enhances the zoom parameter by providing a practical usage hint ('lower the zoom to get city, region or country instead of a street address'), which adds meaning beyond the schema's 'Detail level' list. It also reinforces that location accepts multiple notations, tying back to the schema description.

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 states a specific action ('Find the address or place name') and resource (at a set of coordinates), clearly distinguishing it from siblings by explicitly naming it the inverse of place_geocode. The purpose is unambiguous and immediately differentiates the tool from place_search or coordinate conversion tools.

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?

It provides explicit use cases ('labelling GPS traces, describing a delivery destination, or identifying the administrative area a position falls in') and names the inverse sibling (place_geocode), giving clear guidance on when to use this tool versus alternatives. The zoom tip ('lower the zoom to get city, region or country') further guides selection based on granularity needed.

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?

Annotations already carry readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral details beyond annotations: it searches OpenStreetMap, results are sorted by distance, and results include bearing from the search centre.

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 and front-loaded, beginning with a clear one-sentence summary, followed by concrete use examples, then an explicit pointer to the alternative tool. Every sentence contributes useful 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?

The description is complete for this tool: it explains what the tool searches, the types of results returned, the sorting and bearing behavior, and when to use a sibling tool instead. With a rich input schema, an output schema present, and thorough annotations, nothing essential 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 description coverage is 100%, so the schema fully documents all parameters with defaults and constraints. The description adds contextual examples of category values, but it does not provide meaningful parameter format or semantics details beyond what the schema already states.

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 states a specific verb and resource: 'Find points of interest of a given category near a location' and elaborates with concrete examples and 'Searches OpenStreetMap for facilities by type.' It clearly differentiates from place_geocode by noting that the geocoder is for a single named place.

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 gives explicit use cases such as fuel stations along a route, hospitals near an incident, and EV chargers in a city. It also names the alternative tool, place_geocode, and specifies the condition under which that alternative should be used instead: 'For one specific named place.'

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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses a crucial behavior: it emits a warning when parameters fall outside the model's published validity range, noting that an empirical model out of range still returns a confident number and nothing else catches that. It also clarifies that this is a statistical model over an idealised environment, not a specific path. These are valuable behavioral caveats that annotations cannot convey.

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 front-loaded: the primary purpose appears in the first sentence, followed by use cases, then a critical warning, and finally limitations and alternatives. Every sentence earns its place – no filler or redundant restating of the tool name. The length is justified given the tool's complexity (4 models, 5 environments, 11 parameters) and the need to convey model validity caveats.

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 and the presence of a rich output schema (mentioned as present), the description is complete for calling the tool correctly. It covers the main use cases, warns about out-of-range model use, and clarifies the statistical vs. specific-path distinction. It does not describe the output format in prose, but the output schema handles that. The only minor gap is that it doesn't explicitly state that all parameters are optional, though the schema already shows defaults for all, so that's covered.

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% – every parameter has a description that explains its meaning, units, and defaults. The tool description does not add extra semantic context for individual parameters beyond what the schema already provides. It does explain the interaction between environment and default fade margin, but that's already implied in the schema description for environment. Baseline 3 is appropriate since the schema carries the parameter meaning.

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 opens with a clear verb-object pair ('Calculate maximum allowable path loss and the resulting cell radius') that names the exact resource and output. It further distinguishes itself from siblings by explicitly stating it is not for specific paths ('not "does this exact link clear that ridge?"') and names terrain_profile and rf_towers as alternatives. No ambiguity about what this tool does.

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 use cases ('size cell coverage, compare frequency bands, or check whether a proposed link closes') and explicit exclusions: it answers a statistical coverage question, not a point-to-point path question. It even routes to sibling tools (terrain_profile, rf_towers) for those scenarios. This gives an agent clear when-to-use and when-not-to-use guidance.

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?

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable context beyond that: the conditional backend selection (OpenCelliD vs BeaconDB) and the interpretation of empty results as unmapped areas rather than absence of towers. No contradiction 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.

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

Three tightly scoped paragraphs: a one-line purpose, return/use-case context, and a data-source caveat. Every sentence carries decision-relevant information, and the most important facts are front-loaded.

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?

Combined with the full input schema, output schema, and safety annotations, the description covers purpose, data-source behavior, coverage limitations, and interpretation of results. Nothing needed to invoke the tool correctly 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?

Input schema covers both parameters with 100% description coverage, so the schema already explains location and radius_m. The description does not add parameter-level syntax or format details, but it does not need to given the complete 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?

States a specific verb and resource: 'Find known cell towers near a location.' It also describes the return data (radio technology, operator MCC-MNC, approximate position), making the tool's function unambiguous and distinct from spatial or RF-calculation siblings.

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?

Gives concrete use cases: coverage benchmarking, IoT/fixed-wireless site qualification, and diagnosing poor signal at an address. It also explains the empty-result meaning. It does not explicitly name alternative sibling tools or state when not to use it, so it stops short of a 5.

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?

Beyond the annotations, the description adds high-value behavioral context: no API key needed, OpenStreetMap data via Valhalla, return contents (distance, travel time, turn-by-turn instructions), and size implications of 'full' detail. It also discloses routing-behavior differences such as truck restrictions and walking/bicycle preferences. There is no contradiction with the readOnly/openWorld/idempotent annotations.

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: what it does, what it returns, when to use it, and when to use alternatives. The sentence list of concrete use cases is specific and earns its place, and the alternative-routing guidance is front-loaded after the core purpose. Nothing feels redundant.

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 six parameters and an output schema, the description covers the important contextual ground: data source, no-auth requirement, use cases, and clear routing to siblings. Because an output schema exists, the description does not need to enumerate return fields, and it still communicates the main outputs. This is complete for safe, 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?

Schema description coverage is 100%, so the baseline is 3 even without additional parameter detail. The main description adds broad use context and routing profile awareness, but it does not materially extend parameter semantics beyond what the schema already provides for origin/destination format, via ordering, detail levels, profile restrictions, and coordinate_format. It neither repeats nor compensates heavily, so the baseline 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 opens with a specific verb and resource: 'Get driving, cycling or walking directions along real roads.' It immediately distinguishes this tool from geometry-only tools by emphasizing 'real roads' and from isochrone/matrix tools by stating it returns the path to one place. No ambiguity about what the tool does.

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 states when to use it: 'Use this for anything involving actual travel' with concrete examples. It also names three alternatives and the conditions that select them: geom_measure for straight-line distance, route_isochrone for reachable areas, and route_matrix for multiple origin/destination pairs at once. This is exactly the when-vs-alternatives guidance an agent needs.

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?

Annotations already declare this as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it returns polygons, supports multiple travel modes, explains reverse catchment semantics, and notes that results can be passed directly to geom_relate or geom_overlay.

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 the core purpose, then organized into short paragraphs covering use cases, direction semantics, downstream composability, and the sibling alternative. Every sentence earns its place without unnecessary 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?

For a 4-parameter tool with an output schema and strong annotations, the description covers everything an agent needs: what it does, when to use it, how direction affects results, what the output is, and how it can be consumed by other tools. Nothing important 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%, so the baseline is 3, but the description adds meaning beyond the schema. It clarifies that profile corresponds to drive/walk/cycle time and gives practical guidance on when direction='to' is appropriate, which is more useful than the raw enum descriptions.

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 opens with a specific verb and resource: 'Map everywhere reachable within a travel-time budget.' It clearly distinguishes this tool from route_directions by stating that isochrones are for catchment and accessibility questions, not point-to-point 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?

It explicitly names the use cases (catchment, accessibility, trade areas, coverage) and provides concrete examples. It also gives an exclusion rule: for a path to one specific destination, use route_directions instead, and explains when direction='to' is the correct choice.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds substantial behavioral detail beyond annotations: every origin-destination pair is returned, results are indexed [origin][destination], the nearest destination per origin is included, and unreachable pairs are null. This gives the agent a clear model of the operation's output 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 and front-loaded: first sentence states the core function, second gives representative use cases, third explains return shape, and the final sentence routes to alternatives. Every sentence earns its place 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 output schema exists and annotations are rich, the description is complete for an agent to select and invoke the tool. It covers the matrix semantics, null behavior, and sibling differentiation. No critical missing context is apparent.

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%, so the schema already documents origins, profile, and destinations with examples and defaults. The description reinforces the multi-origin/destination nature but does not add significant new parameter-level semantics. Baseline 3 is appropriate because the schema carries the burden.

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 opens with a specific verb and resource: 'Get road travel times and distances between many origins and destinations at once.' It immediately conveys the batch origin-destination calculation and distinguishes itself from route_directions, route_isochrone, and geom_measure through concrete use cases. This is clearly differentiated from sibling tools.

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 routing guidance: use route_directions for turn-by-turn directions, route_isochrone for time-budget reachability, and geom_measure for straight-line distance. It also gives example analytical questions the tool answers, such as which depot is closest by road. This is exemplary when-to-use versus when-not-to-use guidance.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable behavior: 'Computed offline from astronomical formulas -- no network needed' and the crucial edge-case handling 'Inside the polar circles, events that do not occur are returned as null with an explanation rather than as an error.' This goes beyond annotations to disclose surprising 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 front-loaded with the main purpose and then provides behavioral context and use cases. It is somewhat verbose (multiple paragraphs) but each sentence adds value; the edge-case explanation is useful. It could be trimmed slightly, but it's well-structured.

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 description covers the core function, the offline computation method, the shadow-length ratio with an example, multiple use cases, and the polar-circle null behavior. Since an output schema exists, return-value details are not needed. Nothing essential for calling this tool correctly 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 description coverage is 100%, so both parameters (location and on_date) are already documented. The description does not add any parameter-specific meaning beyond the schema, so the baseline of 3 applies.

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 opens with a specific verb-resource statement: 'Get sunrise, sunset, twilight, golden hour and moon phase for a location.' It also names the shadow-length ratio, a distinct deliverable. This clearly differentiates it from sibling tools like env_weather or time_at_location, even without explicit comparison.

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 rich usage context—'construction shadow studies, right-to-light assessments, solar-panel shading analysis, photography scheduling, crop modelling, delivery windows before dusk, and retail daylight-hours analysis'—and notes it works offline. However, it does not explicitly state when to prefer this over alternatives or when not to use it, so it stops short of a 5.

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?

Beyond the readOnly/idempotent annotations, the description explains the data source (Copernicus GLO-90), resolution (90 m), datum (EGM2008 geoid), and why this differs from GNSS ellipsoidal height. This prevents a real-world misinterpretation of the returned value.

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 and front-loaded: purpose in the first sentence, key return details in the second, and the alternate tool in the third. Every sentence contributes context 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?

For a single-parameter read-only lookup with an output schema present, the description covers units, datum, source, and sibling routing. An agent has everything it needs to invoke the tool correctly and interpret the result.

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 single parameter is already fully described in the schema as 'Position, as coordinates or a place name', so the description adds no extra parameter-level format details. The schema carries the explanatory burden, matching the baseline for 100% schema description coverage.

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 first sentence names the exact operation ('Get ground elevation above sea level at a location') and the description explicitly contrasts it with terrain_profile, so the tool is unambiguously distinguishable from its closest sibling.

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?

It explicitly states when to prefer terrain_profile ('For elevation along a path rather than at one point') and names the sibling, giving clear selection guidance. No important condition is left to inference.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so safety is covered. The description adds valuable behavioral details beyond annotations: it samples along a true geodesic, returns full profile plus statistics, and all samples come from one batched request rather than one call per point. This informs performance expectations and output nature. It does not contradict annotations. The only minor gap is lack of mention of any potential errors or limitations, but given the annotations and output schema, it's more than adequate.

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-loaded with the primary purpose, and each sentence adds value. It starts with the core function, then explains the sampling behavior and statistics, and finally provides usage guidance and differentiation from a sibling. No filler or redundant content. It is well-structured and efficient.

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 tool with three parameters (fully covered by schema), strong annotations (read-only, idempotent, non-destructive), and an output schema, the description covers all essential aspects: what it does, how it behaves (true geodesic, batched), when to use it, and how it differs from the sibling. It leaves no critical gap for an agent to select and invoke it 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%, so the baseline is 3. The description does not add extra meaning to the parameters beyond what the schema already provides; it mentions 'samples' in the context of the tool's action but does not elaborate on the parameter format or constraints. The schema already defines origin, destination, and samples with clear descriptions and bounds. Therefore, 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?

The description states a specific verb ('Get'), a clear resource ('terrain elevation profile'), and the scope ('along a path between two points'). It explicitly differentiates from the sibling tool terrain_elevation by noting this tool samples the straight line between two ends, while the sibling handles single or scattered points. This is unambiguous and distinguishes it from all siblings.

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?

It provides explicit use cases ('cycling and hiking route difficulty, pipeline and cable routing, drainage assessment, or sizing earthworks') and directly names the alternative ('use terrain_elevation') for different scenarios ('single point, or at a scattered set of them'). This leaves no doubt about when to choose this tool over the sibling.

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?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: it is computed offline from a bundled boundary dataset, and it discloses the specific return fields including DST transition timing. This gives the agent useful expectations about data source and behavior without contradicting annotations.

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 and well-structured: a one-line summary, a concise list of return values, a note on the offline computation, and relevant use cases. Every sentence adds value, and the most important information is front-loaded.

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 single-parameter, read-only tool with a rich output schema, the description covers the tool's purpose, return contents, computational basis, and example use cases. Nothing essential is missing for an agent to decide whether and how to invoke it.

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 already describes the single parameter as 'Position, as coordinates or a place name,' so schema coverage is 100%. The description does not add further parameter-level detail such as accepted coordinate formats or how place names are resolved, but the schema already carries the necessary meaning, 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?

The description opens with a specific verb and resource: 'Get the time zone and current local time at a location.' It then enumerates the exact outputs (IANA zone name, local time, UTC offset, DST status, next DST transition), which clearly differentiates it from sibling tools like place_geocode, env_weather, or sun_moon.

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 concrete use cases: scheduling across sites, interpreting GPS timestamps, and delivery/support-window overlaps. It does not explicitly name alternatives or state when not to use this tool, but the context is clear enough for an agent to recognize appropriate invocation scenarios.

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