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?
No annotations are provided, so the description carries the behavioral disclosure burden. It adds useful context: geodesic summation, local computation with no network call or quota, and the explicit non-route scope. It does not discuss error handling or precision limits, but for a read-only measurement tool these are minor.
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, each with distinct value: purpose, route exclusion, and computational behavior. The main purpose is front-loaded and there is 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?
With only one parameter, a detailed schema, and an output schema, the description covers the essential decision factors: what it measures, the geodesic method, the route distinction, and resource impact. Nothing an agent needs to invoke 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% and the LatLon definition thoroughly documents both coordinate formats and longitude-first ordering. The description adds the important 2+ minimum for the points array, something the schema does not enforce, and clarifies the line/order semantics through 'polyline'.
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?
Clearly states it computes the total geodesic length in metres of a supplied polyline of 2+ coordinates. The explicit 'NOT a driven route' and pointer to `route` distinguishes it from the routing sibling, and the polyline framing separates it from point-to-point distance 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?
Explicitly tells the agent to use `route` when a driven route is needed rather than the supplied line, giving a concrete when-not and alternative. The phrase 'the line you supply' implies the intended use case (measuring arbitrary geometry) and the local-computation note reinforces when it is safe to call without quota concerns.
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.