Skip to main content
Glama

HERE route tolls (HGV toll costs and toll roads)

here_route_tolls
Read-only

Calculate HGV route toll costs and toll systems, returning total cost, currency, and per-section fare details so you can estimate trip charges and required toll passes.

Instructions

Calculate the toll cost and toll systems for an HGV route using HERE Routing v8 return=tolls. Returns totalCost (cheapest fare option per toll), totalCostMax (dearest), currency, and per-section toll details including toll system names, country, and every fare product with its validity period and payment methods. Typical UK results include "UK HGV LEVY ENGLAND" (day/week/month passes) and motorway tolls such as the M6 Toll. Passes are alternatives — do NOT sum them; use totalCost for the trip cost. Uses the same "truck" profile (metres/kg) as here_route so toll class is based on real dimensions/axles/emissions. emissionType maps to HERE tolls[emissionType] for Euro-class discounts. For a route summary without tolls use here_route; for traffic incidents on the corridor use here_traffic_incidents.

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": {
      "origin": "<origin>",
      "destination": "<destination>"
    },
    "name": "here_route_tolls"
  }
}

Input Schema

NameRequiredDescriptionDefault
viaNoUp to 10 intermediate waypoints.
avoidNoRoad/area avoidance options.
truckNoHGV profile. Only used when transportMode is "truck".
originYesStart: "lat,lng" or address (auto-geocoded, UK focus).
currencyNoISO 4217 currency for toll prices, default GBP.
arrivalTimeNoArrival time (RFC 3339 with offset). Cannot be combined with departureTime.
destinationYesEnd: "lat,lng" or address.
emissionTypeNoToll emission class (Euro standard), e.g. euro6 — sent as tolls[emissionType].
departureTimeNoDeparture time (RFC 3339 with offset) for traffic-aware tolls.
transportModeNoTravel mode (default truck for HGV tolls; car also accepted).truck

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly and openWorld; the description adds the substantive behavior: the returned fields (totalCost, totalCostMax, currency, per-section toll system/country/fare products), the aggregation semantics of totalCost vs totalCostMax, and realistic UK examples such as the HGV LEVY and M6 Toll. It also discloses that toll class derives from the truck profile and that emissionType maps to HERE tolls[emissionType] for Euro-class discounts.

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

Conciseness4/5

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

Purpose and the key aggregation warning are front-loaded, and the closing sentence routes to alternatives. It is dense but each sentence carries information; a few clauses (e.g. the UK example list) are illustrative padding rather than load-bearing for invocation.

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?

For a 10-parameter tool with nested truck/avoid objects and no output schema, the description covers both the call (HGV profile semantics) and the response shape (cost fields, per-section fare products, validity periods, payment methods). Nothing essential for correct invocation or result interpretation 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 already 100%, so the baseline would be 3; the description still adds value by clarifying the truck profile unit convention (metres/kg), the emissionType-to-tolls mapping, and the currency default behavior in context. It does not explain the less obvious parameters such as tunnelCategory or avoid.tollTransponders, keeping it short of a 5.

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 ("Calculate the toll cost and toll systems for an HGV route") and anchors it to the underlying API mode (return=tolls). It explicitly distinguishes itself from here_route (no tolls) and here_traffic_incidents, so an agent can select it without opening a schema.

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

Usage Guidelines5/5

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

Gives explicit routing guidance: use here_route for a summary without tolls, here_traffic_incidents for corridor incidents. It also gives an in-task usage rule — passes are alternatives, do not sum them, use totalCost for trip cost — which prevents a common misinterpretation of the result.

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