here-hgv-mcp

Decode HERE Flexible Polyline

here_flexible_polyline_decode

Read-only

Decode HERE Flexible Polyline strings into lat/lng point lists for route or isoline geometry, enabling distance checks, bounding boxes, drawing, and stop-on-route validation locally.

Instructions

Decode a HERE Flexible Polyline (the compact geometry returned by HERE Routing v8, Isoline v8 and Map Image v3) into a [lat,lng] point list. Pure local computation — no HERE API call, no quota, no key. Use it when a route/isoline response includes "encoded" polylines and you need coordinates: distances, bounding boxes, drawing, or checking whether a stop lies on the route geometry. Also returns the encoding header (precision, third dimension type) and an optional GeoJSON LineString for direct rendering/mapping. Invalid encodings are rejected with a clear validation error rather than silently producing wrong coordinates.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "encoded": "<encoded>"
    },
    "name": "here_flexible_polyline_decode"
  }
}

Input Schema

Name	Required	Description	Default
`encoded`	Yes	HERE Flexible Polyline string, e.g. "BFoz5xJ67i1B1B7PzIhaxL7Y" or the "encoded" value from here_route includePolyline.
`includeGeoJson`	No	Also return a GeoJSON LineString (coordinates in [lng,lat] order per RFC 7946).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses that this is pure local computation with no API call, quota, or key, that invalid encodings are rejected with a clear validation error instead of silently returning wrong coordinates, and that the output includes the encoding header and an optional GeoJSON LineString. These are the operational facts an agent needs to trust the result.

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

Conciseness5/5

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

The core action and input source come first, then the cost/safety profile, then the use condition, then return shape and error behavior. Every sentence carries distinct information; nothing is padded or restated from the title.

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

Completeness5/5

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 correctly carries the return contract itself: point list, encoding header (precision, third dimension type), and optional GeoJSON LineString, plus failure behavior. For a two-parameter pure-function tool, 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.

Parameters4/5

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 context beyond the schema by identifying where the 'encoded' value originates (HERE Routing/Isoline/Map Image responses) and framing the GeoJSON output as for direct rendering/mapping. It does not explain precision header semantics, but the added framing is genuine.

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

Purpose5/5

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

States a specific verb and resource (decode a HERE Flexible Polyline into a [lat,lng] point list) and names the producing APIs (Routing v8, Isoline v8, Map Image v3), which immediately distinguishes it from the sibling tools that generate such polylines. The scope ('into a [lat,lng] point list') tells an agent exactly what comes out.

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

Usage Guidelines4/5

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

Gives a concrete trigger condition ('when a route/isoline response includes "encoded" polylines and you need coordinates') plus downstream use cases (distances, bounding boxes, drawing, stop-on-route checks). It does not explicitly say when not to use it or name an alternative tool, but the condition is specific enough to route correctly.

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

Deploy Server