norway-location-transport-mcp

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

No annotations are provided, so the description carries the behavioral disclosure burden. It communicates read-only lookup behavior, the official-address scope, and that results include distance, but it leaves unspecified details such as result ordering, truncation by max_results, and the exact address fields returned.

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 compact sentences with no filler. The core action is front-loaded, the data source and distance output follow, and the use case closes it efficiently.

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 geospatial lookup with fully documented parameters, the description plus schema provides enough to invoke the tool correctly and interpret the main result attribute (distance). Without an output schema, a slightly richer return-shape description would help, but the current definition is still sufficient for this tool's complexity.

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 input schema already explains latitude, longitude, radius_m, and max_results with bounds and defaults. The description adds no parameter-specific semantics beyond mentioning radius, so the 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 uses a specific verb and resource: 'Find all official addresses within a radius of a coordinate' and identifies the data source (Kartverket). It clearly distinguishes this tool from siblings like find_place_names_near and find_stops_near by making 'official addresses' the unique target.

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 gives the use case: 'Good for what is at this location?', which tells an agent when to invoke it. It does not name alternatives or exclusions, but the intended context is clear enough without explicit sibling routing.

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 behavioral disclosure burden. It indicates this is a read-only lookup of nearby stations with availability counts, but it does not mention how results are ordered, whether the API has any rate limits or freshness caveats, or what the full response shape is beyond the counts.

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?

A single sentence that front-loads the core purpose, includes a clarifying example, and ends with the most important result detail. There is no redundant 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?

Despite the lack of an output schema, the description names the crucial return elements (vehicle counts and free-dock counts) and the schema fully documents the required and optional parameters. This is enough for an agent to invoke the tool successfully and interpret the main outcome, though a richer response-shape description would make it more 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?

The schema covers all four parameters with descriptions and bounds, and the description does not need to repeat them. It adds only the high-level 'near a coordinate' context, which is already implied by the schema. This matches the baseline for 100% 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 uses a specific verb ('Find'), a precise resource ('shared-mobility docking stations'), a locational anchor ('near a coordinate'), and names the key output fields ('available vehicle and free-dock counts'). This clearly differentiates it from siblings such as find_shared_vehicles and 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 intended use is reasonably implied: find station-based shared mobility around a coordinate. However, the description does not explicitly state when to prefer this over find_shared_vehicles or other nearby-location tools, nor does it give any when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the burden. It discloses the data source (Kartverket), the output contents (feature type and distance), and the spatial nature of the search. However, it doesn't mention rate limits, licensing, whether results are sorted by distance, or potential quirks of named-feature searches (e.g., duplicate names, missing features in remote areas).

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 fluff. The core purpose is stated first, with the result contents and data source packed 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 4-parameter tool with 100% schema coverage, the description is mostly complete. It doesn't mention output ordering (likely by distance), pagination, or error behavior (e.g., out-of-bounds coordinates), but these are minor given the simple output and descriptive 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%, so the schema already documents all four parameters with descriptions, defaults, and ranges. The description reinforces that results are distance-based, adding slight meaning beyond the schema by noting 'nearest' and 'distance from the point.' This exceeds the baseline 3 but doesn't add extensive semantic detail.

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 ('Find') and resource ('nearest official named features to a coordinate'), names the data source (Kartverket), and highlights what each result includes (feature type and distance). It clearly distinguishes itself from siblings like find_stops_near and find_addresses_near by focusing on official named features.

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 tool is for finding named places/features near a coordinate, which gives clear context for when to use it versus alternatives like find_addresses_near or find_stops_near. However, it doesn't explicitly state when not to use it or name alternative 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does describe the result shape and scope, but it does not mention data freshness, rate limits, or whether this is strictly a read-only operation. There is nothing misleading, but the operational behavior is only partially disclosed.

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 cover the resource type, scope, examples, and result fields with no filler. The most important information is front-loaded, and every clause contributes meaning.

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

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

For a read-oriented search tool with fully documented parameters, the description is largely complete. It explains what results contain and the geographic scope, though it does not mention pagination limits or that the schema's count/range defaults exist; these are already in the schema and are minor 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?

The input schema has 100% parameter description coverage, so the schema already documents latitude, longitude, count, range_m, and form_factors. The description adds only the high-level concept of searching 'near a coordinate', which does not replace or enrich the per-parameter semantics beyond the baseline.

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

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

The description uses a specific verb ('Find') and names the exact resource ('free-floating shared vehicles') with concrete examples and a geographic scope. It clearly distinguishes itself from sibling tools like find_docking_stations by emphasizing 'free-floating' and 'all Norwegian operators'.

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 this tool through the phrase 'free-floating shared vehicles' and the operator scope, but it does not explicitly say when not to use it or name alternatives such as find_docking_stations or get_vehicle_positions. Usage context is clear but exclusions are left to inference.

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

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

There are no annotations, so the description must carry behavioral details. It states the core behavior (returns nearest stops with distance) but does not mention error handling, sorting guarantees beyond 'nearest', radius application details, or any limits on result size beyond the schema's max_results. It also does not clarify whether the tool is read-only or how it behaves when no stops are found.

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 is well-structured and front-loaded with the core action ('Reverse-geocode a coordinate'). It avoids unnecessary verbiage and flows logically, making it 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?

The description adequately conveys that the tool returns nearby stops with distances and that IDs can be used further, but since there is no output schema, it lacks detail on the exact structure (e.g., whether it includes names, coordinates, or just IDs). It also does not mention potential edge cases or how the radius interacts with the 'nearest' criterion, leaving some contextual 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 coverage is 100% (all parameters have descriptions). The description itself adds no new meaning to the parameters; it only mentions 'nearest' and 'distance' which relate to the result rather than the inputs. Per the rubric, with high schema coverage, a score of 3 is the baseline, and no additional parameter context is provided.

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 action: reverse-geocode a coordinate to the nearest public transport stop places (Entur) and return each with its distance. It also hints at the intended downstream use of the IDs with departure and trip tools, which reinforces the purpose.

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 mentions using the returned IDs with departure/trip tools but does not explicitly contrast this tool with sibling tools like find_place_names_near or find_docking_stations. It lacks explicit guidance on when to prefer this over alternatives, though the fact that it specifically targets public transport stops is 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?

Since no annotations are provided, the description carries the burden of behavioral disclosure. It does disclose that results include realtime delays, cancellations, and a defined set of fields. However, it does not mention whether cancelled departures are still included in the count, whether results are sorted chronologically, or any data freshness/availability caveats. For a read-only tool this is acceptable but not richly transparent.

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 purpose is front-loaded, and the second sentence compactly enumerates the returned fields. 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?

There is no output schema, so the description must convey what the tool returns. It does this well by listing line, destination, scheduled and expected times, delay, platform, and cancellation status. Minor gaps remain, such as ordering and whether cancelled departures are filtered, but the core information an agent needs is present.

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

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

Schema description coverage is 100%, so both parameters are already well documented with types, defaults, ranges, and an example. The tool description adds no new parameter-specific meaning beyond what the schema provides. The baseline score of 3 is appropriate because the schema does the heavy lifting.

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

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

The description clearly states a specific action (get next departures), a specific resource (a stop place), and the Entur data source. It is immediately distinguishable from sibling tools like find_stops_near or get_realtime_status because it focuses on departure data with realtime delay and cancellation information.

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 establishes the clear context for when to use this tool: when upcoming departures from a stop are needed, including realtime updates. The stop_place_id parameter description explicitly directs the agent to resolve IDs via resolve_stop_place, providing a concrete workflow hint. No explicit exclusions or alternative tool mentions are given, but none of the siblings covers departures, so the usage context is clear.

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

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

With no annotations provided, the description carries the full burden. It usefully discloses the unit (metres above sea level), data source, and coverage area. However, it does not describe the return shape, error behavior for points outside mainland Norway, or other service behaviors, leaving some gaps for a tool without 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 tight sentences with no filler. The core operation, unit, source, and coverage are all front-loaded and every clause adds value.

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

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

For a simple point-elevation lookup, the description plus schema covers the essentials: parameters, coordinate system, bounds, unit, source, and geographic scope. It could be more complete by mentioning what to use for an elevation profile, but it 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?

Schema description coverage is 100%, and both latitude and longitude already have clear descriptions with bounds and WGS84 context. The description adds no new parameter-level detail, 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 states a specific verb and resource: 'Get the terrain elevation (metres above sea level) at a coordinate.' It also identifies the data source (Kartverket DTM) and geographic scope, making it easy to distinguish from sibling tools like get_elevation_profile.

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 clearly implies this tool is for a single point elevation lookup and explicitly notes it only covers mainland Norway. It does not explicitly route users to alternatives such as get_elevation_profile for elevation series, so it stops short of full when/where-not guidance.

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

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

With no annotations, the description carries the full burden. It discloses the sampling algorithm ('evenly'), the data source (Kartverket DTM), and the computed returns (total distance, ascent, descent). It stops short of stating units (meters) or edge-case behavior, but for a read-only geodata tool this is meaningful transparency.

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

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

Three sentences, front-loaded with the core action and returns, followed by use case and a parameter pointer. No 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 2-param tool with a fully documented schema and no output schema, the description explains what the agent receives (profile plus distance, ascent, descent) and the input ordering. Complete enough to call correctly; units and the exact profile structure are left unspecified, a minor gap given the tool's simplicity.

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%: path is described as ordered vertices with the path sampled evenly between them, and samples as the number of evenly spaced points. The description's 'give the path vertices in order; `samples` controls resolution' largely restates schema content, adding only the framing that samples maps to resolution.

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 ('Sample'), resource ('terrain elevation along a path of coordinates'), and outcome ('return the profile plus total distance, ascent, and descent'), and cites the Kartverket DTM data source. The path/profile framing clearly distinguishes this from sibling get_elevation, which is presumably single-point.

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?

'Useful for hikes and routes' gives an intended use case, and 'Give the path vertices in order' clarifies input handling. However, it never explicitly contrasts this with get_elevation or states when not to use it, leaving the tool-selection decision to inference.

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

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

With no annotations provided, the description must carry behavioral disclosure. 'Get' implies a read-only lookup and '(Entur)' identifies the data source, which is useful. However, it does not disclose return shape, multiplicity behavior, or error handling for invalid stop IDs.

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 action is front-loaded, followed by a one-line explanation of why fare zones matter. Every part 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 simple single-parameter lookup, the description plus schema is largely complete: it states the purpose, the required input format, and the source of valid IDs. There is no output schema, so the return representation is left somewhat unspecified, but the description adequately conveys that the result is the stop's fare zone(s).

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 stop_place_id with a pattern, example, and source hint. The description adds domain context but no additional parameter-level semantics beyond what the schema provides.

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

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

The description uses a specific verb and resource: 'Get the fare (tariff) zone(s) a stop place belongs to'. It clearly identifies the Entur domain and distinguishes this from sibling departure, accessibility, and quay tools.

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

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

The description gives clear context by explaining that fare zones set the ticket price, which implies when this tool is relevant. The input schema also directs the agent to obtain stop_place_id from resolve_stop_place. It lacks explicit when-not-to-use guidance, but no obvious alternative fare-zone tool exists.

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 behavioral burden and does so well: it discloses exactly what each mode reports, such as counts of on-time/delayed/cancelled departures and vehicle activity/delays. It does not mention output structure or behavior when both/no parameters are supplied, which is a minor gap.

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

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

Two concise sentences, with the core purpose front-loaded and each sentence devoted to one input mode. There is no redundant or filler 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?

The description is adequate for common stop-or-line use, but because there is no output schema and no annotations, the lack of guidance on whether exactly one parameter is required and what happens when neither is supplied is a real gap. It also only sketches the response shape rather than naming specific fields.

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

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

The schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds value by explaining the semantic difference between the two parameters and what result each triggers, justifying a 4. However, the exclusivity of the two parameters is left implicit.

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

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

The description states a specific verb ('Get'), a clear resource ('realtime health summary'), and differentiates the two input modes with concrete outcomes. This distinguishes it from siblings like get_departures and get_vehicle_positions, which return raw data rather than aggregated health summaries.

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 usage context: pass stop_place_id for a stop-level summary and line_id for a line-level summary. It does not explicitly compare against sibling tools or state when not to use this tool, so it stops short of 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 behavioral burden and does so well: it reveals the data source, the per-quay granularity, and the explicit limitation that deeper equipment detail is unavailable. It stops short of describing response shape or error behavior, 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 tightly written sentences earn their place: the first front-loads the operation and output scope, the second adds a valuable limitation without redundancy. No wasted words.

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

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

The one required parameter is fully documented and the description states what the response will contain at a high level. Since there is no output schema, a little more detail about the exact response shape would be ideal, but nothing needed to select or invoke the tool correctly is missing.

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

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

The input schema already gives 100% coverage for stop_place_id, including format, example, and a pointer to resolve_stop_place, so the tool description adds no extra parameter semantics. Baseline 3 is appropriate because the schema fully carries this weight.

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

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

The description names a specific verb and resource: getting accessibility information for a stop place, with a concrete scope (per-quay wheelchair access plus a summary). It does not explicitly contrast with a sibling tool, so it falls just short of full differentiation, but the Entur and per-quay context makes the 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 note explicitly states when not to use this tool (when elevators or tactile guidance are needed) and names the alternative (Entur's authenticated Stop Register API). The parameter description also directs the agent to resolve_stop_place to obtain the required ID, so invocation context is fully covered.

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 behavioral disclosure burden. It explains the data source (Entur realtime), the per-vehicle fields returned (position, bearing, speed, delay), and the filtering model. It does not specify behavior when no filters are supplied, but as a read-only position lookup this is a minor gap rather than a hidden side effect.

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

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

The description is compact and front-loaded with the core action and resource. Each sentence earns its place: the filtering model, the output fields, codespace examples, and the cross-reference to get_departures. There is no redundant filler.

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

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

Given there is no output schema, the description appropriately summarizes what each vehicle object contains. Parameter documentation is handled by the schema, and the description adds the missing operational context. It could be slightly more explicit about the default when neither filter is provided, but overall it is sufficient for selecting and invoking the 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 value beyond the schema by giving concrete codespace examples and telling the agent to source line_id from get_departures. This makes the optional relationship between the two filters more actionable.

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 and resource: 'Get live positions of public transport vehicles (Entur realtime)', and adds the filtering dimensions (codespace and/or line). This clearly distinguishes it from sibling tools like get_departures or find_stops_near, which target different resources or 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?

It gives clear usage context: use this tool when you need live vehicle positions, optionally filtered by operator or line. It also tells the agent how to obtain a valid line_id via get_departures and provides concrete codespace examples. It does not explicitly list exclusions or alternatives, but the guidance is sufficient for correct routing.

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 burden of behavioral disclosure. It clearly signals a read-only listing and specifies the output fields, which is useful. However, it does not mention ordering, potential absence of quays, or any additional behavior beyond listing.

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 states the core action, clarifies terminology, and lists the returned data without redundancies. Every phrase adds information.

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-parameter list tool, the description is largely sufficient: it names the input source, the resource being queried, and the output contents. The lack of an output schema is partially offset by the enumerated result fields, though pagination or edge-case behavior is not mentioned.

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

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

Schema description coverage is 100%, and the parameter description is detailed with an ID pattern and example. The tool description itself adds little beyond the schema, but since the schema already fully documents stop_place_id, 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 uses a specific verb and resource: 'List all quays ... at a stop place' and enumerates the returned data (public codes, coordinates, wheelchair access). This clearly distinguishes it from sibling tools like get_departures or get_stop_accessibility, which address different concerns.

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 clearly implies a use case: querying the platforms of a given stop place. The schema adds the prerequisite 'Get one from resolve_stop_place', giving the agent concrete context for how to obtain a valid stop_place_id. It does not explicitly state when to avoid this tool or name alternatives, but the context is clear.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description explains what it returns (municipality, county, official codes) but doesn't disclose edge-case behavior: what happens if the coordinate is outside Norway, if the address is ambiguous, if both address and coordinate are provided, or if neither is provided. Since it has no required parameters, an agent could call it with zero arguments and the behavior is undocumented. With no annotations and no output schema, this is a significant transparency 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?

Two sentences with no filler. The core purpose and required output (municipality, county, official codes) are stated first, and the input alternatives follow immediately. 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?

With no annotations and no output schema, the description serves as the primary guide for the agent. It covers what the tool takes and what it returns, which is enough for a straightforward lookup. However, there are gaps: precedence between address and coordinate, behavior for missing/outside-Norway inputs, and whether the output includes names only or also codes (it says with official codes, so codes are clear). For a geospatial lookup with this sibling context, the description is adequate but not fully 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%, meaning all three parameters are documented in the schema itself: address, latitude, and longitude. The description adds the high-level relationship between them ('Give either a coordinate or a free-text address'), which is useful for disambiguation. However, it doesn't clarify precedence if both are given, nor does it specify expected address format beyond what the schema says. Baseline 3 is appropriate when the schema covers parameters fully.

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: finding which municipality (kommune) and county (fylke) a location falls in, including official codes from Kartverket. It also distinguishes itself from siblings by specifying the exact resource (administrative units) and explicitly listing the two accepted input types (coordinate or free-text address). This makes it easy for an agent to differentiate from address search or geocoding tools like search_address or validate_address.

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 it: when you need administrative unit membership or codes for a location. It explicitly states that either a coordinate or a free-text address can be given, providing usage flexibility. However, it doesn't explicitly say when NOT to use it or name alternative tools for similar lookups, though the sibling list and clear resource focus provide some differentiation.

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 behavioral burden. It discloses that the tool only returns open address-linked identifiers, not ownership data, and identifies the data source. It does not cover edge cases such as supplying both address and coordinate or providing neither, but the scope limitation is clearly stated.

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

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

Three short sentences; the main purpose is front-loaded, the input acceptance is stated in one sentence, and the limitation is at the end. No filler.

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

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

Given no output schema, the description compensates by naming the returned identifiers and the data source. For a tool with four optional parameters and a Norwegian cadastral domain, it is adequately complete for an agent to invoke it correctly, though it could state behavior when no lookup input is supplied.

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 documents all four parameters. The description adds the meaningful 'or' relationship between free-text address and coordinate lookup, which is not encoded in the schema, but it does not elaborate on max_results 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 names a specific resource ('cadastral identifiers for a property'), a concrete data source (Kartverket open address register), and lists the exact returned fields (municipality number, gnr, bnr, festenummer). It clearly distinguishes the tool from the broader authenticated Matrikkel API and from sibling address/search tools by its focus on matrikkel 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 states when to use it: looking up property identifiers from a free-text address or coordinate, and explicitly flags that full ownership data is outside this tool's scope and requires the authenticated Matrikkel API. It does not explicitly reference sibling tools like search_address or lookup_admin_unit, but the input and exclusion guidance gives clear enough 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 behavioral disclosure burden. It explains that the tool returns trip patterns with legs, modes, durations, and realtime times, which goes beyond the schema. It does not disclose every edge case, but for a planning tool the behavior is sufficiently transparent.

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

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

The description is compact and front-loaded: purpose first, then endpoint requirements, optional parameters, and output. Every sentence adds useful information with no 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?

Given 11 parameters and no output schema, the description does a good job covering the essential behavior and return contents. It could mention how to obtain Stop Place IDs or what happens if both ID and coordinates are supplied, but the core information needed to call the tool correctly is present.

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 meaningful parameter semantics by explaining that each endpoint can be either a Stop Place ID or coordinates, which is not obvious from the flat schema alone. It also summarizes the optional time, mode, and walk speed parameters.

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 ('Plan'), a clear resource ('point-to-point public transport journey in Norway'), and names the underlying system (Entur JourneyPlanner). This distinguishes it from siblings like get_departures or find_stops_near, which handle different transit lookup tasks.

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 clearly communicates the core usage context: point-to-point journey planning with endpoint and optional constraints. It does not explicitly name alternatives or exclusions, but the context signals from sibling tools make the intended use obvious enough.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It conveys that this is a read-only lookup/conversion returning IDs and implies possible multiple results via the plural 'IDs' and max_results schema. It does not describe matching semantics, failure behavior, or response structure, so transparency 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 short sentences with no filler. The first sentence defines the operation and output, and the second explains downstream integration. It is front-loaded and compact.

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 no output schema, the description explains the input domain and the returned concept (Stop Place IDs) and lists the consuming tool families. Adding matching behavior or result format details would improve it, but an agent has enough 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?

Schema description coverage is 100%, so the schema already documents query and max_results. The description reinforces that the input is a place or address text value but adds no independent parameter details beyond the schema. 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 operation ('Turn a place or address into Entur Stop Place IDs'), names the resource domain (public transport stops/stations), and clarifies that the output is to be consumed by downstream transit tools. This clearly distinguishes it from address, docking-station, and place-name sibling tools.

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

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

It provides clear context for when to use the tool: whenever a free-text place or address must be converted into a Stop Place ID for departure, trip, accessibility, quay, or fare-zone operations. However, it does not explicitly contrast itself with alternatives like find_stops_near or search_place_names, so it lacks when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden. It discloses wildcard support and the exact returned fields (coordinates, postal code, municipality, cadastral numbers), which is valuable behavioral context for a search operation. It does not mention rate limits or empty-result behavior, but these are not critical for basic use.

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

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

Three sentences with no filler: purpose is front-loaded, usage modes follow, and the return contents are listed last. 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 six-parameter tool with no output schema, the description covers invocation modes, wildcard behavior, and returned data. It does not describe coordinate reference systems or error handling, but those are not essential 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 coverage is 100%, so the baseline is 3. The description adds value by clarifying the relationship between `query` and the structured fields, and by explicitly highlighting wildcard usage with an example, going slightly 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?

States a specific verb and resource: searching official Norwegian addresses (Kartverket) and returning coordinates. The 'Norwegian' and 'official' qualifiers clearly distinguish it from generic place-name or property search tools among the siblings.

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

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

Explicitly explains the two invocation modes: free-text `query` or structured fields. It does not explicitly contrast against sibling tools like validate_address or search_place_names, but the intended usage context is clear enough for an agent to proceed.

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 behavioral burden. It clearly discloses useful search behaviors: wildcard support, spelling-error correction, and the return fields (feature type, municipality, county, coordinates). It is transparent for a read-only-style search tool, though it does not mention rate limits or error 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 focused sentences with no filler. It front-loads the core purpose, then adds return-value detail and search behaviors that are not obvious from the schema. Every sentence contributes useful information.

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 two-parameter search tool with no output schema, the description is nearly complete: it explains what is searched, what is returned, and key query behaviors. It could be slightly richer by clarifying coordinate format or pagination behavior, but those are minor 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%, so the schema already documents both parameters well. The description adds behavioral meaning for 'query' (wildcard and spelling correction), but it does not need to add more for 'max_results' because that is fully covered 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 uses a specific verb ('Search') and a specific resource ('official Norwegian place names (Kartverket Sentralt stedsnavnregister)'). It also lists what is returned, which distinguishes it from nearby siblings like search_address and lookup_admin_unit.

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 this is the right tool when searching by place name rather than by address, proximity, or administrative unit. However, it does not explicitly state when not to use it or name alternatives such as find_place_names_near or search_address.

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 bears full responsibility for behavioral disclosure. It discloses axis order (x=easting, y=northing) and gives commonly used EPSG codes, which are valuable behavioral hints. However, it does not mention error behavior (e.g., invalid EPSG codes), precision/accuracy, or whether the transformation is exact or approximate. For a conversion tool with no annotations, this is adequate but 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 concise and well-structured: a single purpose sentence, a sentence on axis order, and a list of common EPSG codes. No fluff; every sentence contributes meaningful information. It front-loads the core function and then provides immediately actionable 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?

Given the tool's simplicity (4 required parameters, no output schema, no annotations), the description covers purpose, parameter semantics, axis order, and practical examples. The only notable omission is an explicit statement of the return value format (e.g., transformed x,y in target EPSG), but that is strongly implied by the tool name and description. For a straightforward coordinate conversion, this is nearly 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?

The schema already describes each parameter (x, y, from_epsg, to_epsg) with clear examples, giving 100% coverage. The description adds semantic depth beyond the schema by explaining the axis-order convention and listing example codes for each system. This goes beyond simple parameter documentation and helps an agent format inputs correctly.

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 function: 'Convert a coordinate between reference systems using Kartverket's transformer.' It specifies a verb, resource, and context (Kartverket), and is distinct from all sibling tools which handle address/stop/trip lookups, not coordinate transformations. An agent can immediately understand what this tool does.

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

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

The description implies when to use this tool (when converting coordinates) and provides practical usage details like common EPSG codes and axis order. While it doesn't explicitly exclude alternatives, none of the sibling tools perform coordinate conversion, so the intended use is clear. It lacks explicit 'when not to use' guidance, but that's not critical given the isolated purpose.

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

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

The description discloses key behavioral traits beyond the schema: fuzzy matching, spelling error correction, and the return of valid status, the best match, and alternatives. With no annotations provided, this is useful transparency, though it does not explicitly confirm that the operation is read-only or describe any underlying data source limitations.

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 efficient and well-structured: purpose is stated first, followed by behavior and return values. Every sentence adds useful information without unnecessary filler.

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

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

For a simple single-parameter tool with no output schema, the description covers the essential context: what the tool does, how it behaves with fuzzy matching, and what it returns. It is sufficient for an agent to select and invoke it, though more explicit return shape details could improve completeness.

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

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

Schema description coverage is 100%, and the single parameter is already documented with a concrete example. The description adds the nuance that the input is free-text, but it does not need to compensate for missing parameter documentation.

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 and resource: checking whether a free-text address exists in the official register and returning its normalized form with coordinates. It is distinct in behavior, but it does not explicitly differentiate itself from the sibling tool search_address, which may also handle address-like queries.

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 intended use is implied through the description: validate and normalize an address. However, there is no explicit guidance on when to choose this tool over search_address or other sibling tools, and no exclusions or alternative recommendations are provided.

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