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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds behavioral details beyond those: results are sorted by distance, and category filters accept both predefined shortcuts and arbitrary OSM key/value pairs. It does not describe pagination or rate limits, but given the output schema exists and the tool is read-only, this is a reasonable level of disclosure.

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: it opens with the core purpose, then provides the category shortcut list (which is necessary for usability), and closes with a pointer to the sibling tool. Every sentence serves a purpose – no fluff. The long list is justified because it enumerates valid values that are not in 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?

Given the tool's complexity (5 parameters, 2 required) and the existence of an output schema, the description covers all critical aspects: what it does, how to filter (categories, OSM tags), and where to go for more detail. It doesn't explain default values for limit, radius_m, or language, but those are documented in the schema. The description is complete for an agent to correctly invoke the tool and interpret results (with 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?

While the input schema covers 100% of parameters, the description adds substantial semantic value, especially for the category parameter. It lists dozens of valid shortcuts (restaurant, cafe, museum, etc.) and explains the OSM tag syntax ('key' or 'key=value'). It also clarifies that 'near' can be coordinates or place names, reinforcing the schema but with practical guidance. This is far beyond baseline for a schema-covered parameter.

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 'Finds points of interest near a location, sorted by distance' – a specific verb, resource, and sorting behavior. It also distinguishes itself from poi_details by pointing to that tool for full records, and from geocode/reverse_geocode by implying location lookup is integrated. The category shortcuts and OSM tag syntax further clarify the exact scope of what can be searched.

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

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

It explicitly names an alternative ('Use poi_details for the full record of one result') and gives a condition for when to switch. While it doesn't enumerate exclusions for every sibling (e.g., suggest_meeting_point, isochrone), the core purpose is unambiguous enough that an agent can infer when to use this tool versus those. The description also clarifies that arbitrary OSM tags can be used, expanding the tool's applicability.

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=false. The description adds behavioral details: uses OpenStreetMap, returns multiple matching places with coordinates and OSM id, and explains provider differences. This goes beyond the annotations without contradicting them.

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?

Two sentences, front-loaded with the primary action, no redundancy. Efficient 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?

Given the output schema and full parameter descriptions, the description provides sufficient context for correct usage. It explains the tool's purpose, return content, and provider choices. Minor gaps like error handling are not necessary for basic usage.

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 all parameters with descriptions (100%). The description adds semantic meaning for the provider parameter, explaining when to choose nominatim vs photon, which is not in the schema. Other parameters are adequately described in the schema, so the description adds marginal value.

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 place name or address into coordinates using OpenStreetMap, specifying the verb and resource. It implicitly distinguishes from reverse_geocode by the direction of conversion but does not explicitly name the sibling tool, so it is clear but not fully differentiating.

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 guidance on provider selection (nominatim vs photon) but does not specify when to use this tool versus alternatives like reverse_geocode or routing tools. No explicit when-not-to-use or alternative tool recommendations are given.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds behavioral detail about the return format: 'a compact summary of the reachable area: bounding box and reach per compass direction.' It also discloses the exclusivity constraint on minutes/kilometers, which is not in the schema. This is valuable context beyond annotations.

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

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

Two sentences with zero waste. The main purpose is front-loaded, followed by an example, output summary, and a crucial constraint. Every sentence serves a purpose, and the description is compact and easy to parse.

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 (5 params, 2 required) and the presence of an output schema (which covers return details), the description covers the essential usage and output summary. It does not discuss error handling or edge cases like invalid coordinates, but that is not expected for a well-documented tool. The constraint on minutes/kilometers is clearly stated. It is sufficiently complete for an agent 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 60%, with minutes and kilometers lacking descriptions. The description clarifies these as mutually exclusive budget parameters ('time or distance budget') and gives an example that ties profile and minutes together. It also explains the output meaning, which indirectly helps interpret parameters. This adds meaning beyond the schema, though it doesn't detail all parameters (e.g., language) – but those are already described in 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 states a specific verb ('Shows how far you can get') and resource ('from a place within a time or distance budget'), and gives a concrete example ('what is reachable in 15 minutes on foot?'). This clearly distinguishes it from siblings like route (path) or route_matrix (multiple paths) by focusing on the reachable area rather than a specific 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 provides a clear use case with an example and explicitly instructs 'Give exactly one of minutes or kilometers,' which is a critical usage constraint. It does not explicitly name alternatives like route or suggest when not to use it, but the scenario is evident enough for an agent to infer appropriate 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=true, idempotentHint=true, and destructiveHint=false, so the tool is safe and non-mutating. The description adds behavioral context by noting the output is for opening in a browser and describes the two link types. It does not contradict annotations and provides useful context beyond what annotations cover.

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 two sentences, front-loading the core purpose and then stating the input requirement. There is no filler; every word adds value. The structure is clean and easy to parse quickly.

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 five optional parameters, an output schema, and no required fields. The description covers the two usage modes completely, and the schema covers the details of profile and language. With the output schema present, no explanation of return format is needed. The description is fully adequate for an agent to invoke this 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 coverage is 100%, so all five parameters are documented. The description adds the crucial semantic that 'place' and ('from' + 'to') are mutually exclusive, which is not encoded in the schema. It also clarifies that 'from' and 'to' are used together for directions, while 'place' is for a marker link. This goes beyond the schema's individual parameter 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 clearly states the tool generates OpenStreetMap links, distinguishing between marker links (single place) and directions links (from/to). It uses a specific verb ('Generates') and resource ('openstreetmap.org links'), and implicitly differentiates from siblings like geocode or route by focusing on link generation rather than data retrieval.

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 the input requirements: either 'place' or both 'from' and 'to'. It does not explicitly mention when to avoid this tool in favor of alternatives, but the purpose (generating browser links) is distinct enough that an agent can infer when it is appropriate. The mutual exclusivity constraint 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the roundtrip semantics (default true returns to first stop, false treats first as start and last as end), which is not covered by annotations. It also mentions the return includes total distance and time, adding useful behavioral context beyond the safety hints.

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?

Two sentences with zero waste. The first sentence front-loads the core purpose and output, the second clarifies the roundtrip option. No redundant filler or repetition of schema details.

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 TSP tool. It covers the essential behavior (optimization, roundtrip), the return (itinerary, distance, time), and the output schema exists to detail the exact structure. Annotations cover safety and idempotency. Nothing critical is missing for an agent 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 75% (actually all parameters have descriptions, so coverage might be higher, but given the signal). The description does not add much beyond the schema: it explains roundtrip behavior, but the schema already says 'Return to the first stop at the end, default true'. The description's explanation is slightly more detailed but adds marginal value. No new parameter information is introduced.

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 a specific verb ('Finds the best order') and resource ('set of stops') with the traveling-salesman optimization context. It distinguishes itself from siblings like route or route_matrix by focusing on optimization rather than simple pathfinding, making its purpose unmistakable.

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 explains the roundtrip behavior but does not explicitly state when to use this tool versus alternatives. It does not mention that for a simple A-to-B route one would use 'route', or that for multiple routes 'route_matrix' is appropriate. Usage context is implied by the optimization focus but not spelled out.

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, covering safety. The description adds value by specifying the returned data types (tags, coordinates, map link) and the expected input format, which goes beyond annotations. It doesn't mention limitations like response size or rate limits, but the core behavior is transparent and consistent 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?

Two sentences, zero waste. The first sentence states the purpose and output, the second specifies the input source and format. The description is front-loaded with the action and resource, making it easy to scan. Every word 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?

Given a single parameter, an output schema (present), and annotations covering safety, the description is complete. It tells the agent exactly what to provide, where to obtain it, and what to expect in return. No critical information 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?

With schema description coverage at 0%, the description fully compensates by explaining the 'osm_id' parameter: it comes from find_nearby_pois or geocode and gives a concrete example ('node/240109189'). This matches the schema's pattern and clarifies the expected format. No other parameter exists, so the description completely resolves 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 states a specific verb ('Fetches') and a clear resource: 'the full OpenStreetMap record of one element'. It enumerates the returned content (tags, coordinates, map link) and gives a concrete input example, making the tool's purpose unambiguous. It distinguishes itself from siblings by focusing on a single element's details rather than search or routing.

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 ties its input to results from find_nearby_pois or geocode, telling the agent when this tool is appropriate (as a follow-up to those searches). It doesn't explicitly name alternatives or exclusions, but the context of 'one element' and the stated input source effectively guides usage. The lack of an explicit 'when not to use' is a minor gap.

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 false, so the basic safety profile is covered. The description adds useful context by mentioning 'nearest' (approximate result) and Nominatim (external service), but does not disclose potential rate limits, data accuracy caveats, or other behavioral traits that could affect invocation expectations.

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 a single, well-structured sentence that front-loads the primary action and names the underlying provider. Every word earns its place and there is no redundant or vague wording.

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 three parameters, rich safety annotations, and an output schema, the description is nearly complete. The only notable gap is the lack of explicit guidance distinguishing reverse_geocode from geocode, but this is partially mitigated by the tool name and the description's clear phrase 'coordinates into address.'

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 only 33%, with only the 'language' parameter described. The description does not compensate for the low coverage: it says 'coordinates' without clarifying coordinate format (e.g., WGS84) or adding meaning to latitude/longitude beyond what the property names and numeric ranges already imply. It also omits any mention of the language parameter's effect.

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 ('converts') and resource ('coordinates into the nearest address or place name'), making the tool's purpose unmistakably reverse geocoding. The name itself also clearly differentiates from the sibling geocode tool, even without an 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 implies the core use case: provide latitude/longitude and get a location name. However, it does not explicitly state when to use this over the sibling geocode tool or any other alternative, leaving the agent to infer the boundary between forward and reverse geocoding.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds context beyond annotations: it specifies the data source (OpenStreetMap), the order-fixed behavior, and the optional turn-by-turn steps via include_steps. No contradictions; the added behavioral detail is useful but not exhaustive (e.g., no mention of network assumptions or error 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?

Two sentences with zero redundancy. The core action is front-loaded, the order constraint is stated, and the sibling routing is given at the end. 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?

An output schema exists, so return format details are not required in the description. The tool handles 2–25 waypoints with fixed order, multiple profiles, and optional steps—all key behaviors are covered. It lacks mention of coordinate format (but schema covers that) and doesn't discuss error cases, but given the annotations and schema coverage, it is 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 description coverage is 100%, so the schema already documents all parameters. The description adds meaning by clarifying that waypoints are visited in order (schema says 'Start, optional stops in between, destination' but description makes it explicit) and that include_steps provides a turn-by-turn summary, which reinforces the schema's boolean description. This goes slightly beyond the 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 the tool computes real-world travel distance and time between two or more places using walking, driving, or cycling on OpenStreetMap data. It distinguishes itself from siblings by explicitly naming route_matrix (compare many pairs) and optimize_route (reorder stops), so an agent can tell them apart without opening the schema.

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 says 'Use route_matrix to compare many pairs, optimize_route to reorder stops,' providing clear when-not-to-use guidance. It also implies this tool is for a single route with a fixed order, which is directly stated by 'Waypoints are visited in the given order.' This gives an agent explicit routing logic for 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 destructiveHint, so the safety profile is clear. The description adds useful behavioral context beyond annotations: cells are null where no route exists, and the batch nature is highlighted by 'in one call'. This enriches the agent's understanding without contradicting the 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?

Two sentences with zero fluff. The main function is front-loaded, followed by a use-case example and a behavioral note about null cells. Every word 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?

An output schema exists, so return format is covered. Annotations cover safety and idempotency. The description covers the null case and the batch behavior, which are essential for correct invocation. Sibling differentiation is aided by the 'one call' phrasing. Nothing critical is missing for an agent to use this 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 high (all parameters have descriptions: origins/destinations format, profile enum, language default). The tool description does not add parameter-level detail beyond what the schema already provides, so the baseline 3 is appropriate—it relies on the schema for parameter 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 states a specific verb ('Computes'), a clear resource ('travel times and distances'), and the exact scope ('from every origin to every destination in one call'). The matrix nature distinguishes it from sibling tools like 'route' which likely handles a single pair, so an agent can differentiate without opening the schema.

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 a concrete use case: comparing multiple options (e.g., 5 hotels against 3 sights), which implies when this tool is appropriate. It does not explicitly mention when not to use it or name alternatives, but the context and sibling names (e.g., 'route') make the single-pair case obvious.

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 behavioral traits beyond annotations: 'Instant' and 'independent of any road network', which inform performance and functional scope. 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?

Two sentences with zero waste. The core definition is front-loaded, and the alternative routing guidance is delivered in a compact second sentence. Every word 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 tool is simple, has an output schema, and all parameters are fully documented in the schema. The description covers purpose, method, and alternative selection, leaving nothing essential missing 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?

Schema description coverage is 100%, with each parameter (to, from, language) having a clear description including the 'lat,lon' format. The tool description adds no additional parameter-level semantics beyond what the schema provides, so baseline 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?

States a specific verb+resource: computes great-circle ('as the crow flies') distance between two places. Clearly distinguishes itself from route by defining the calculation method and explicitly naming the sibling it is not.

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 instructs to use route for real travel distances, giving an unambiguous alternative and the condition that selects it. The description leaves no ambiguity about when this tool is appropriate.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful algorithmic context: it finds venues around the midpoint and selects the one with most balanced travel times, which is beyond the annotations. This provides insight into how the tool behaves, though it doesn't mention potential limitations like routing dependency or failure modes. Still, the added algorithm detail is valuable.

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 two sentences, front-loaded with the primary purpose and then the mechanism. Every word earns its place; there is no fluff or redundancy. It efficiently communicates the tool's essence without unnecessary detail.

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 and full parameter descriptions, the description provides sufficient context for an agent to understand the tool's purpose and algorithm. It doesn't explain the return format, but that's covered by the output schema. It could be more explicit about the dependence on routing for travel time calculation, but this is implied by 'travel times'. The description is complete enough for correct invocation without major 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?

Schema description coverage is 100% with all five parameters having descriptions in the schema. The tool description does not add parameter-specific details beyond the schema, but it gives contextual meaning to parameters like 'locations' and 'profile' through the concepts of geographic midpoint and balanced travel times. Per the rubric, baseline is 3 when schema coverage is high, and the description does not compensate with additional parameter 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 the tool's purpose: suggests a fair meeting point for people starting from different locations. It also explains the mechanism (finds venues around the geographic midpoint, picks the one with most balanced travel times), which distinguishes it from siblings like find_nearby_pois and route_matrix. This is a specific verb+resource description that leaves 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 provides clear context for when to use the tool: when participants start from different locations and need a fair meeting point. It implicitly communicates the use case but does not explicitly mention alternatives or when not to use it. While it's clear from the sibling list that this is the dedicated meeting-point tool, the absence of explicit routing to alternatives prevents a perfect score.

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