Total length in metres of a polyline through 2+ coordinates, summed geodesically. This measures the line you supply, NOT a driven route , use route for that. Local computation: no network call, no quota.
| Name | Required | Description | Default |
|---|---|---|---|
| points | Yes | The coordinates to consider. |
| Name | Required | Description | Default |
|---|---|---|---|
| length_m | Yes | Total geodesic length in metres. |
Changes observed during successful MCP inspections.
Input schema / $defs / LatLon / anyOfAdded value: +[
+ {
+ "properties": {
+ "lat": {
+ "description": "Latitude in decimal degrees (−90 to 90).",
+ "format": "double",
+ "type": "number"
+ },
+ "lon": {
+ "description": "Longitude in decimal degrees (−180 to 180).",
+ "format": "double",
+ "type": "number"
+ }
+ },
+ "required": [
+ "lat",
+ "lon"
+ ],
+ "type": "object"
+ },
+ {
+ "description": "GeoJSON position [lon, lat]: longitude FIRST.",
+ "items": {
+ "format": "double",
+ "type": "number"
+ },
+ "maxItems": 2,
+ "minItems": 2,
+ "type": "array"
+ }
+]Input schema / $defs / LatLon / descriptionPrevious value: -"A WGS84 coordinate pair in decimal degrees."New value: +"A WGS84 coordinate in decimal degrees: a {lat, lon} object (preferred), or a GeoJSON [lon, lat] array with LONGITUDE FIRST, the same order as every polygon field on this server."Input schema / $defs / LatLon / propertiesRemoved value: -{
- "lat": {
- "description": "Latitude in decimal degrees (−90 to 90).",
- "format": "double",
- "type": "number"
- },
- "lon": {
- "description": "Longitude in decimal degrees (−180 to 180).",
- "format": "double",
- "type": "number"
- }
-}Input schema / $defs / LatLon / requiredRemoved value: -[
- "lat",
- "lon"
-]Input schema / $defs / LatLon / typeRemoved value: -"object"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral load and does well by disclosing that this is a local, quota-free computation and that the result is summed geodesically rather than routed. It could say more about edge cases such as antimeridian handling or minimum-point validation, but the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core computation and followed immediately by the key routing distinction and execution context. There is no filler, and everything needed is easy to scan.
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 geometry tool with an output schema and rich nested schema definitions, the description supplies everything an agent needs: what is measured, how it differs from `route`, units, and that there is no network or quota impact.
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 `points` structure, coordinate formats, and coordinate order are already fully documented in the schema. The description adds useful semantic context by specifying that a polyline requires 2+ coordinates and that measurements are geodesic, going beyond the schema’s brief 'The coordinates to consider.'
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 computed quantity: total polyline length in metres, summed geodesically, for a supplied set of 2+ coordinates. It also explicitly distinguishes this from a driven route by naming `route` as the correct alternative, which is the main sibling confusion.
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 an explicit when-not rule: use `route` for driven routes, while this tool measures the line you supply. It also states a key usage condition: local computation with no network call and no quota.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.