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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions that each result includes a distance, but it does not state that the operation is read-only, does not mention any side effects, rate limits, or pagination behavior. For a typical address lookup this is likely a safe read, but that is not explicitly communicated.

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

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

The description is extremely concise, two sentences with no filler. The main purpose is front-loaded in the first sentence, and the second sentence adds a valuable detail about the output plus a use case. 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?

For a straightforward lookup tool with a fully documented schema, the description covers the core query intent and gives a hint about the return value (distance). It lacks an explicit statement about output structure (e.g., address fields) or ordering, but given the simple nature and the absence of an output schema, the description is reasonably complete. A small addition about response shape could bump it to 5.

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 fully documents all parameters (100% coverage), including latitude/longitude ranges and radius/max_results limits. The description adds no additional parameter semantics; it only mentions the output includes distance, which is not parameter-related. Baseline 3 is appropriate given complete schema 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 description clearly states the verb 'find' plus the resource 'all official addresses' and the scope 'within a radius of a coordinate'. It also names the data source (Kartverket) and a typical use case ('what is at this location?'), which distinguishes it from sibling tools like find_place_names_near or find_stops_near.

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 use case ('Good for what is at this location?') but does not explicitly state when to prefer this tool over alternatives, nor does it mention exclusions or conditions for using other tools. The guidance is implied but not explicit enough to fully navigate the large sibling set.

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

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

With no annotations, the description carries the full burden. It discloses the core behavioral outcome (returns station counts) but does not mention ordering, pagination, error conditions, authentication requirements, or any side effects. For a simple read-only tool this is adequate but not exhaustive; it leaves some behavioral aspects to inference.

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 core purpose and key output. Every word earns its place; there is no fluff or repetition. This is exemplary conciseness.

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

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

Given the tool's simplicity and full schema coverage, the description is largely complete. It states the return content (available vehicle and free-dock counts) and the geospatial scope. Without an output schema, it could mention ordering or result format, but these are minor omissions for a straightforward query tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds nothing about parameter semantics beyond what the schema already documents (e.g., count, range_m, lat/long). Since the schema provides complete descriptions for all four parameters, the description does not need to compensate, so a 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 ('Find'), a concrete resource ('shared-mobility docking stations'), and a clear scope ('near a coordinate'), plus the key output ('available vehicle and free-dock counts'). This unambiguously differentiates it from siblings like find_shared_vehicles or get_vehicle_positions, which target vehicles rather than stations.

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: it is for finding docking stations (e.g., city bike stations) near a given coordinate with per-station counts. It does not explicitly name alternatives or exclusions (like 'use find_shared_vehicles for free-floating vehicles'), but the intent is obvious enough that an agent can select it correctly. Lacks explicit when-not guidance, so not 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?

With no annotations provided, the description carries the full burden. It discloses the output format (feature type and distance) and names the data source, but omits important behavioral caveats such as the Norway-only coordinate range (only present in schema), handling of no results, or any rate limits. This is adequate but not thorough.

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, front-loaded sentence that clearly states the core purpose and output. There is zero waste; every word contributes value, and the key information is presented at the beginning.

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 straightforward lookup tool with complete schema coverage and no output schema, the description provides essential output details (feature type, distance) and the data source (Kartverket). It lacks mention of edge cases like empty results or pagination, but these are minor given the tool's simplicity and annotated 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?

The schema provides 100% coverage with descriptive details for all four parameters (latitude/longitude ranges, radius_m and max_results defaults and limits). The description adds no extra meaning beyond what the schema already states, so it meets the baseline without surpassing it.

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 ('find') and a clear resource ('nearest official named features to a coordinate') with a source (Kartverket) and output details (feature type and distance). This differentiates it from siblings like find_addresses_near and find_stops_near, despite not naming them.

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 usage when a coordinate is known and official place names are needed, but it does not explicitly mention alternatives or when not to use this tool. Sibling tools such as search_place_names or find_addresses_near are not referenced, leaving routing to the agent implicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the tool is read-only, has any side effects, requires authentication, or has rate limits. It only describes the result shape, leaving the safety and operational profile undisclosed.

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, and the result fields are listed efficiently. Every word contributes to clarity.

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

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

The description covers the essential purpose and result shape, but it lacks details on ordering, pagination, or behavior when no vehicles are found. Without an output schema, these gaps could matter, though the basic result fields are stated. It's adequate but not 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 baseline is 3. The description adds context about 'free-floating' and 'across all Norwegian operators', which clarifies the coordinate usage and the meaning of form_factors (type filter), but it does not add significant parameter-specific details 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 states a specific verb ('Find'), a specific resource ('free-floating shared vehicles'), a clear scope ('near a coordinate across all Norwegian operators'), and lists the fields returned. It clearly differentiates this from siblings like find_docking_stations (since it's free-floating, not docked) and find_stops_near (vehicles vs stops).

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 context that implies usage (find vehicles rather than stops or docking stations), but it does not explicitly state when to use this tool versus alternatives such as get_vehicle_positions or find_docking_stations. The 'free-floating' qualifier helps, but no exclusions or alternative routing 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?

With no annotations provided, the description must carry the burden of behavioral disclosure. It correctly states the tool performs reverse geocoding and returns distances, which is fundamental behavior. However, it does not address edge cases, result ordering, or any limitations (e.g., geographic scope of Entur data), leaving some behavioral aspects implicit.

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 sentence with a clear purpose followed by a practical usage note. It is front-loaded with the core function and contains zero redundant words or filler.

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

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

The description is adequate for an agent to call the tool correctly: it specifies coordinates, mentions optional parameters exist (implicitly via schema), and tells the agent how to use the output (with departure/trip tools). It lacks an explicit explanation of the output format, but the absence of an output schema and the simplicity of a stop list make this acceptable.

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 schema already documents all four parameters with descriptions and ranges. The tool description adds no extra semantics beyond what the schema provides (e.g., it does not elaborate on how radius_m or max_results affect results). This meets the baseline for high schema 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 description states a specific verb ('Reverse-geocode') and resource ('nearest public transport stop places'), and clarifies the output includes distance. It also distinguishes from sibling tools like find_addresses_near and find_place_names_near by focusing on public transport stops, and mentions the downstream use of returned IDs, making its purpose distinct.

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 by stating 'Use the returned IDs with the departure and trip tools,' which tells the agent when this tool is relevant. However, it does not explicitly exclude alternatives or mention when not to use it, though the focus on stops implies differentiation from address/place tools.

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

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

With no annotations, the description must convey behavioral context. It discloses that the tool returns realtime delays and cancellations and lists the output fields, which is useful. However, it does not explicitly state read-only nature, error handling, or potential rate limits. The description provides moderate transparency but leaves important behavioral aspects implicit.

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, with the primary action stated first and the output structure succinctly enumerated. Every clause adds value, wasting no words. It is front-loaded with the core purpose and then provides complementary 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?

For a tool with two parameters and full schema coverage, the description adequately explains what the response contains (line, destination, scheduled/expected times, delay, platform, cancellation). It omits potential error scenarios or time zone assumptions, but given the simplicity of the operation, the description covers the essential context an agent needs to 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?

Both parameters are fully described in the schema (stop_place_id and count), so schema coverage is 100%. The description does not add significant meaning beyond what the schema already documents—it only repeats the stop concept and adds output context, not parameter details. This matches the baseline of 3 for high schema 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 description states a specific action ('get the next departures') on a specific resource ('a stop place (Entur)') and highlights distinguishing features (realtime delays and cancellations). This clearly differentiates it from sibling tools like plan_trip or get_realtime_status, which serve different purposes.

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

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

The description does not provide guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites (other than a hint in the schema), or conditions that would favor get_departures over plan_trip or get_realtime_status. Agents would need to infer usage from the tool name and sibling 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?

With no annotations provided, the description must carry the full behavioral disclosure. It does state the data source and coverage (mainland Norway) and explicitly gives the unit (metres above sea level), which is useful. However, it omits any behavior for out-of-range coordinates (e.g., error vs. no data), any mention of read-only safety (obvious but not stated), and any details about the response format. The coverage note adds some context but leaves significant gaps for a tool with no annotation 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?

The description is a single, tightly written sentence that leads with the core purpose, then adds the data source and coverage. Every word contributes information, with no redundancy or clutter. It is an exemplary model of conciseness.

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 single-point elevation tool, the description covers the essentials: what it returns (elevation), units, and source. However, the absence of an output schema and annotations means the agent is left uninformed about error behavior (e.g., what happens for coordinates over water or outside Norway) and the exact response structure. While the tool is straightforward, a more complete description would mention these edge cases, so it does not reach a 4.

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

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

Schema coverage is 100%, with both latitude and longitude fully described including WGS84 and allowed ranges. The description adds the context of the elevation model and coverage but no additional meaning about the parameters themselves. Since the schema already defines them thoroughly, the description provides no extra semantic value, meeting the baseline of 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 action ('Get the terrain elevation'), the specific resource (Norwegian national elevation model), the unit (metres above sea level), and the condition (a coordinate). It is immediately evident what the tool does and how it differs from the sibling get_elevation_profile, which implies a multi-point profile. No ambiguity remains.

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 what the tool does but never addresses when to use it relative to sibling tools. For instance, it does not explicitly recommend get_elevation_profile for a series of points or clarify that this tool is only for single-point queries. No exclusions or alternatives are mentioned, leaving the agent to infer the appropriate 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?

No annotations are provided, so the description carries the full burden. It implies a read-only sampling operation, but it does not explicitly state that it has no side effects or requires no special permissions. It does disclose the data source (Kartverket DTM), which adds some transparency, but notable operational details (e.g., coordinate system limits) are not mentioned beyond the schema.

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

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

The description is two sentences with no filler. It front-loads the purpose, then adds a direct usage hint. Every clause contributes meaning, and it avoids repeating schema information. It is optimally concise for its content.

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 no output schema, the description appropriately lists what is returned (profile, total distance, ascent, descent), covering the main output expectations. It also mentions the data source and usage context. It does not detail potential edge cases or units, but for a path-sampling tool this is reasonably 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?

Although the schema already provides full parameter descriptions, the description adds value by instructing 'Give the path vertices in order' and clarifying that 'samples controls resolution.' This goes beyond the schema's definition of samples as a count and provides practical guidance on ordering, which is essential for correct output.

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 samples terrain elevation evenly along a path and returns a profile plus distance, ascent, and descent. The verb 'sample' and resource 'terrain elevation along a path' are specific and distinct from the sibling get_elevation, which likely handles single points. It also notes the data source (Kartverket DTM), adding precision.

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 notes it is 'useful for hikes and routes,' giving a context for use, but it does not explicitly state when to prefer this over get_elevation or other alternatives. There is no explicit exclusion or comparison to sibling tools, leaving the differentiation to inference from the path-based nature.

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

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

No annotations are provided, so the description must carry the behavioral burden. It describes a read operation ('Get') and adds useful context about Entur and ticket pricing, but it doesn't explicitly state that the operation is read-only, nor does it mention error handling, potential multiple zones, authentication requirements, or return format. For a simple lookup, this is acceptable but not rich.

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 purpose is front-loaded in the first sentence, followed by context in the second. No filler or repetition, making it efficient for an agent 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 a single parameter and a clear purpose. The description explains what it does and why it matters (ticket price). It doesn't describe the output structure, which could be a gap since no output schema exists, but for a simple zone lookup this may be sufficient. It's complete enough for an agent to decide when to call it and what to expect conceptually.

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%—the schema fully documents stop_place_id with pattern, example, and source hint. The description adds no additional parameter details beyond what's in the schema, so the baseline 3 applies. It doesn't contribute extra semantic meaning about how the parameter relates to the result.

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

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

The description clearly states the verb 'Get' and resource 'fare zones', and adds context that these zones determine ticket prices. This uniquely identifies its function among siblings, which cover addresses, places, departures, and trips but none specifically for fare zones. The distinction is immediate and unambiguous.

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

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

The description implies when to use the tool: when needing fare zones for a stop. It doesn't explicitly name alternatives or exclusions, but given the sibling list, no other tool offers this capability, so an agent can infer correct usage. The added context about ticket price reinforces its purpose, but a more explicit routing statement would elevate it.

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

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

No annotations are provided, so the description carries the full burden. It discloses what kind of output to expect (counts of on-time/delayed/cancelled for stops, active vehicle counts and delays for lines) and implies a read-only operation. However, it does not address edge cases like both parameters being supplied, invalid IDs, or data freshness/rate limits, leaving some behavioral gaps.

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 with no filler. The primary verb and resource are front-loaded, and the two usage modes are explained in parallel structure. Every clause earns its place, making it both concise and scannable.

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 no output schema and only two optional parameters, the description covers the core usage and expected result types. It explains what each mode returns, which is sufficient for a simple status summary. It falls short of specifying what happens if neither or both parameters are provided, and does not outline error handling, but these are minor for a low-complexity tool.

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

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

Schema description coverage is 100%, so the schema already documents both parameters with types, patterns, and context. The description adds a bit of semantic clarity by explaining the relationship between the parameter and the summary type, but it essentially reiterates the schema info without adding substantial new meaning. Hence a 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's purpose as 'Get a realtime health summary' and then breaks down the two distinct modes: stop-level (summarizing on-time/delayed/cancelled departures) and line-level (active vehicles and delays). This specific verb+resource framing distinguishes it from siblings like get_departures (raw departures) and get_vehicle_positions (vehicle locations), which are different 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 gives explicit guidance on which parameter to pass for which scenario ('For a stop, pass stop_place_id' and 'For a line, pass line_id'), making selection clear. However, it does not explicitly contrast with alternative tools (e.g., 'use get_departures for detailed times') or state when not to use this tool, so it stops short of full exclusion criteria.

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

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

With no annotations provided, the description carries the full burden. It transparently discloses what data is returned (per-quay wheelchair access plus summary) and what is deliberately excluded (equipment detail), along with the data-source context of Entur's free vs authenticated API. This goes beyond the bare minimum, though it does not state output format or authentication requirements.

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 concise sentences with the core purpose front-loaded and the limitation stated in a clear note. No redundancy or filler; 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?

For a single-parameter read-only tool with high schema coverage, the description covers purpose, data scope, and known limitations. It lacks explicit return structure details, but given no output schema, the high-level description of 'per-quay wheelchair access, and a summary' is sufficient for an agent to invoke and interpret the result. Minor gap is the absence of response field names.

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

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

Schema coverage is 100% and the parameter description already includes pattern, example, and guidance to obtain from resolve_stop_place. The tool description adds no additional parameter semantics, which is acceptable given the schema's high coverage, 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 states a specific verb ('Get'), resource ('a stop place'), and the precise scope ('per-quay wheelchair access, and a summary'). It is immediately distinguishable from sibling tools like list_quays or resolve_stop_place, which serve different purposes.

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

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

The description conveys its scope and limitation (deeper equipment detail not available), but it does not explicitly name alternative tools or conditions for when to use them. It implies that for elevator/tactile detail you'd need a different API, but no sibling tool is suggested, so the agent must infer the alternative.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses that each vehicle shows position, bearing, speed, and delay, which is useful. However, it does not describe behavior when both or neither filter is provided, whether the call is read-only, or any rate limits. This is a partial disclosure but lacks completeness.

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—three sentences—and front-loads the core purpose immediately. It avoids unnecessary verbosity while including practical examples. The structure flows logically from purpose to filtering details to param acquisition hint.

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 no annotations or output schema, the description covers essential aspects: purpose, filtering options, examples, and how to get a line_id. Gaps include unspecified behavior when parameters are omitted, but the given information is sufficient for an agent to make a correct initial call. Given the moderate complexity, this is fairly complete.

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

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

Schema description coverage is 100%, so parameters are already documented. The description adds value by explaining the relationship between line_id and codespace_id ('and/or'), providing concrete examples for codespace (ATB, KOL, SKY), and indicating how to obtain line_id from get_departures. This goes beyond the schema and helps the agent construct valid calls.

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 gets live vehicle positions in real-time, specifies it is filtered by codespace and/or line, and distinguishes it from sibling tools like get_departures by focusing on positions rather than schedules. The verb 'Get' and resource 'live positions of public transport vehicles' are specific and unambiguous.

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

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

The description provides context on how to obtain a line_id via get_departures and gives example codespaces, but it does not explicitly state when to prefer this tool over alternatives (e.g., for real-time vehicle tracking vs. departures), nor does it specify exclusions or fallback conditions. Usage guidance is implied rather than explicit.

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

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

No annotations are provided, so the description must disclose behavioral details. It states the tool returns certain fields but omits any mention of error handling, empty results, pagination, or the response format. For a list operation with no output schema, this is a notable gap.

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

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

The description is a single, tightly worded sentence that front-loads the main action and lists key output attributes. There is no redundant phrasing or unnecessary detail, making it highly 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?

The description covers the essential purpose and core output fields, but without an output schema, it lacks a full specification of the response structure, edge cases, or error conditions. It is adequate for a simple list operation but leaves some ambiguity for an agent.

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

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

The input schema fully describes the stop_place_id parameter, including format and an example, with 100% coverage. The tool description adds no additional parameter meaning, so the baseline of 3 is appropriate since 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 states a specific verb (list), a specific resource (quays at a stop place), and lists the output fields (public codes, coordinates, wheelchair access). It clearly differentiates this tool from siblings like get_stop_accessibility or resolve_stop_place, which serve different purposes.

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

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

The description only explains what the tool does, not when to use it or when to prefer alternatives. There is no statement about choosing this tool over other stop-related tools. The only guidance appears in the schema description (getting the ID from resolve_stop_place), which relates to parameter acquisition, not usage 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys a read-only lookup via the verb 'Find' and mentions official codes, but it does not specify what happens when both coordinate and address are supplied, whether the address must be within Norway, or any error behavior. The return format is also left unspecified, which is a notable gap since there is no output schema.

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

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

The description is a single, concise sentence that front-loads the core purpose and then states the two accepted input forms. It contains no filler or redundant information, achieving maximum clarity per word.

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 lookup tool, the description is mostly adequate: it names the output (municipality, county, official codes) and the input options. However, it lacks some details such as precedence when both address and coordinate are provided, whether the address must be geocodable within Norway, and the exact response structure (especially given there is no output schema). These gaps are not severe but prevent full completeness.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explicitly stating 'Give either a coordinate or a free-text address,' clarifying the mutual exclusivity and reinforcing that a coordinate implies both latitude and longitude are required together. This goes beyond the schema's parameter-level descriptions and helps the agent construct valid calls.

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 operation: 'Find which municipality (kommune) and county (fylke) a location falls in,' and specifies input options (coordinate or free-text address) and data source (Kartverket). It is distinct from sibling tools like search_address, though it does not explicitly contrast itself with them, so it loses one point for lacking explicit 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 provides no guidance on when to use this tool versus siblings like search_address or validate_address. It only explains how to provide input (either coordinate or address), not the conditions that would make this tool the right choice. No exclusions or alternatives are mentioned, leaving the agent without decision criteria.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the data source (Kartverket's open address register), the scope (returns identifiers, not ownership), and the limitation (ownership requires a different API). This goes beyond a bare statement and gives the agent a clear picture of what to expect, though it omits details like error handling or rate limits, which keeps it from a 5.

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, no filler. The purpose is front-loaded with the specific identifiers, and the second sentence succinctly covers inputs and the ownership limitation. Every sentence earns its place, making it an exemplary model of concise structure.

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 no required parameters, the description effectively communicates the output and the limitation. However, it doesn't explicitly state that at least one of address or coordinate must be provided, which could lead an agent to call it with no arguments. Given the tool's simplicity and the absence of an output schema, this minor gap prevents a perfect score.

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 parameters have descriptions. The tool description adds the guidance to 'Give a free-text address or a coordinate,' which reinforces the choice between address and coordinate parameters but doesn't add syntax or constraints beyond what the schema already provides. Per the baseline rule for high coverage, this is a solid 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 states a specific action (look up cadastral identifiers), a specific resource (property matrikkel info via Kartverket's open address register), and lists the exact identifiers returned (municipality number, gnr, bnr, festenummer). This clearly differentiates it from sibling tools like search_address, which likely return address components rather than cadastral identifiers.

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 tells the agent how to invoke it ('Give a free-text address or a coordinate') and provides a clear exclusion: 'Full ownership data requires Kartverket's authenticated Matrikkel API.' This implies when NOT to use this tool (when ownership is needed) but doesn't explicitly name an alternative sibling. It gives context but lacks an explicit 'use this instead of X' statement, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool returns ('trip patterns with legs, modes, durations, and realtime times'), which is useful, but it does not mention whether the operation is read-only, any rate limits, error handling, or what happens when no route exists. It also does not disclose external API dependencies beyond the Entur name. This is a partial disclosure, not comprehensive.

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 with no redundant wording. The first sentence establishes the tool's core purpose and service, while the second succinctly covers endpoint specification, optional settings, and output. Every clause contributes useful information, and the most critical scoping statement ('point-to-point') 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 tool with 11 parameters and no output schema, the description covers the key calling conventions: endpoint types, optional time/mode/walk speed settings, and the shape of the return value. It does not explicitly explain that each endpoint can be independently given as either Stop Place ID or coordinates (the phrasing 'either as a Stop Place ID or as coordinates' could be read as a collective choice), nor does it mention that only one of the two origin specifications should be provided. However, the schema itself clarifies these details, so the description is largely sufficient.

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 description coverage is 100%, so the baseline is 3. The description adds value by explaining that endpoints can be provided either as Stop Place IDs or as coordinates, which clarifies the relationship between the from_place/to_place parameters and the latitude/longitude fields. It also mentions that departure/arrival time can be set, transport modes filtered, and walk speed changed, which maps to the optional parameters and provides context beyond the schema's field-level 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's purpose: planning a point-to-point public transport journey in Norway, backed by Entur JourneyPlanner. It specifies the verb 'plan' and the resource 'public transport journey', and the phrase 'point-to-point' distinguishes it from sibling tools like get_departures which handle single-stop departures. The description is specific and unambiguous.

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

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

The description gives context on how to provide endpoints ('either as a Stop Place ID or as coordinates') and mentions optional parameters, but it does not explicitly state when to use this tool versus alternatives such as get_departures or resolve_stop_place. There is no exclusionary guidance like 'for single-stop departures use get_departures instead', so the usage context is implied rather than explicitly routed.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It implies a non-mutating lookup operation and names the external source (Entur), which is useful context. However, it does not disclose the return format, how multiple candidates are returned, error/no-match behavior, or rate-limit expectations. It adds domain context but leaves edge behaviors to inference — acceptable, not complete.

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 filler. The core action is front-loaded in sentence one, and the downstream-consumer guidance in sentence two earns its place by telling the agent how to chain the result. Compact 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 simple 2-parameter resolver with full schema coverage, the description is reasonably complete: it states the action, the output type, and the downstream use of the ID. Gaps are that no output schema exists (so return shape is unspecified) and ambiguous-match or no-match handling is undocumented. Adequate but with noticeable holes for a resolver.

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%: 'query' is documented with a concrete example ('Oslo S' or 'Bergen busstasjon') and 'max_results' with default/min/max bounds. Since the schema already carries the parameter meaning, the baseline is 3; the description's reference to 'place or address' merely echoes the query parameter's schema text and adds negligible new information.

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 pairs a specific verb ('Turn a place or address into') with a precise resource ('Entur Stop Place IDs'), and clarifies the domain (public transport stops/stations). It is implicitly differentiated from overlapping siblings like search_address, search_place_names, and validate_address by its outcome type (a Stop Place ID consumed by transport tools), though it never names a sibling explicitly to distinguish against — the distinction is implied by outcome rather than stated.

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 clear downstream context: 'Use the returned ID with the departure, trip, accessibility, quay, and fare-zone tools.' This tells the agent this tool is the prerequisite step for a family of transport queries, a concrete and actionable usage signal. However, it does not state exclusions or point to alternatives (e.g. 'for plain addresses use search_address, for raw names use search_place_names'), so competitors remain unspecified.

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

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

With no annotations provided, the description carries the full burden. It discloses key output fields (coordinates, postal code, municipality, cadastral numbers) and wildcard support. However, it does not mention behavior on empty results, rate limits, authentication requirements, or the read-only nature (though it is implicit in a search). It is adequate but not exhaustive.

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 with no filler. The purpose is front-loaded, and the key usage hints (wildcard, return fields) are presented efficiently. 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?

For a search tool with 6 parameters and no output schema, the description covers essential context: what it returns, how to use free text vs. structured fields, and wildcard support. It does not describe error handling or limits, but the schema covers parameter constraints. The return-field disclosure compensates for the missing 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 description coverage is 100% (all 6 parameters have descriptions). The description adds marginal value by clarifying the free-text vs. structured search distinction and giving a wildcard example, but the schema already documents each parameter's meaning. 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 states a specific verb ('Search') and resource ('official Norwegian addresses (Kartverket)'), which clearly distinguishes it from sibling tools like search_place_names and find_addresses_near. It unambiguously signals this is an address lookup, not a place-name lookup.

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 internal usage guidance: 'Use query for free text, or the specific fields for a structured search.' However, it does not explicitly state when to prefer this tool over alternatives (e.g., search_place_names) or what it should not be used for. The exclusion of place-name searches is implied but not stated.

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

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

With no annotations provided, the description carries full responsibility. It discloses functional behavior: returns feature type, municipality, county, coordinates, supports wildcard, and corrects small spelling errors. This adequately informs the agent about the tool's read-only, search-like nature, though it omits details like result sorting or empty-result 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 three sentences, front-loaded with the core purpose, then the return fields, then the special features. Every sentence contributes useful information with no redundancy or filler, making it easy for an agent to scan 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?

This is a relatively simple read-type search tool. The description covers what it does, what it returns, and key behavioral nuances (wildcard, spelling correction). The schema handles parameter details, and no output schema is required since the description enumerates the return fields. Nothing an agent needs to call it 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 coverage is 100%, so both 'query' and 'max_results' are already documented. The description adds the wildcard mention and spelling correction, but these duplicate the schema's query description ('Supports the * wildcard'). Per the rubric, when schema coverage is high, the baseline is 3, and no significant extra meaning is added beyond what schema properties already convey.

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 ('Search official Norwegian place names'), immediately distinguishing it from sibling tools like search_address (addresses) and find_place_names_near (proximity). It further states what is returned (feature type, municipality, county, coordinates), making the tool's purpose unambiguous.

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

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

The description gives clear context: it is for searching official Norwegian place names, and it highlights the wildcard and spelling correction features. However, it does not explicitly contrast with find_place_names_near or other alternatives, leaving the decision of when to use this vs. siblings partially implicit.

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

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

With no annotations, the description must carry behavioral disclosure. It discloses the axis order (x=easting, y=northing with latitude/longitude clarifications) and names the backing service (Kartverket's transformer), which is useful. However, it does not state what the tool returns, whether it is read-only, error behaviors, or rate limits. Core conversion behavior is implied but incomplete for an agent that has no prior knowledge.

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 with no redundancy. The first sentence states the purpose and service, the second gives axis order and common codes. It front-loads the core action and packs essential usage details efficiently. 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?

For a coordinate transformation tool with no output schema and no annotations, the description provides essential input guidance (axis order, EPSG codes) but omits the return format. An agent would not know whether the result is in the same axis order, what the output structure is, or how errors are surfaced. The description is adequate for invoking but incomplete for interpreting the response, especially given the lack of 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% with each parameter described, so the baseline is 3. The description adds value beyond the schema by explicitly explaining the axis order convention (easting/longitude for x, northing/latitude for y) and providing a list of common EPSG codes with their axis orientation. This helps the agent choose correct values and understand coordinate system nuances not fully captured in the schema's short 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 converts a coordinate between reference systems using Kartverket's transformer. It names the specific resource and operation, and differentiates from all siblings, none of which perform coordinate transformation. The inclusion of common EPSG codes further clarifies 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 provides clear instructions on how to call the tool (give EPSG codes, correct axis order) but does not explicitly say when to use it versus alternatives. There are no similar sibling tools, so lack of alternative guidance is not critical, but the dimension asks for explicit when-to-use context. It implies usage for any coordinate conversion need but does not state exclusions or conditions.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It transparently states that fuzzy matching is used to correct small errors, and it lists the returned components (valid, best normalized match, alternatives). It does not mention potential side effects or edge cases (e.g., if no match is found), but the core behavior is clearly communicated.

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

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

The description is two concise sentences with no fluff. The primary purpose is front-loaded, followed by the fuzzy-matching behavior and a concise summary of return values. 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?

Given a single parameter and no output schema, the description provides sufficient context: it explains what the tool does, the fuzzy matching behavior, and the structure of the response. It could optionally mention error handling or the exact format of the normalized address, but it is complete enough for an agent to 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?

With only one parameter and 100% schema description coverage, the schema already fully documents the 'address' parameter. The tool description adds no additional parameter semantics beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: validating and normalizing a free-text address against an official register, with a returned normalized form and coordinates. It differentiates from sibling search tools by emphasizing validation and normalization rather than general search.

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 usage when you have an address that may contain spelling errors and need to check its validity against an official register. It does not explicitly contrast with sibling tools like search_address, find_addresses_near, or find_place_names_near, leaving the agent to infer the appropriate context.

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