here-hgv-mcp

HERE traffic incidents (closures, accidents, roadworks)

here_traffic_incidents

Read-only

Retrieves live traffic incidents within a bounding box, circle, or corridor, with filters for type and severity, so you can identify road closures and critical disruptions for HGV planning.

Instructions

List live traffic incidents within a bounding box, circle or corridor using HERE Traffic API v7. Returns incident id, type (accident/construction/roadClosure/roadHazard/…), criticality (low/minor/major/critical), localised description and summary, start/end time, road-closed flag, affected length and an OLR location reference. Filter by criticality and type. locationReferencing defaults to ["olr"]; use ["shape"] if you need geometry points (adds size). For HGV planning: roadClosures and critical incidents are the ones to surface to a driver first — combine with here_route avoid areas if a closure blocks the planned corridor. Note: HERE returns all matching incidents; limit truncates the returned list only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "here_traffic_incidents"
  }
}

Input Schema

Name	Required	Description	Default
`at`	No	Centre "lat,lng" for a circular area. Requires radiusM.
`bbox`	No	Bounding box [west, south, east, north] in degrees, e.g. [-2.35,53.42,-1.50,53.83] for Greater Manchester.
`lang`	No	BCP-47 language for descriptions, default en-GB.
`limit`	No	Maximum incidents to return (default 50).
`types`	No	Filter by incident type, e.g. ["roadClosure","accident"].
`units`	No	Units for descriptions (default metric).	metric
`radiusM`	No	Radius in metres for the circular area around "at" (used only with at).
`criticality`	No	Filter by severity, e.g. ["major","critical"].
`latestEndTime`	No	Only incidents ending at/before this RFC 3339 UTC time.
`corridorRadiusM`	No	Corridor half-width in metres (used only with corridorPolyline).
`corridorPolyline`	No	HERE Flexible Polyline for a corridor filter (e.g. a here_route includePolyline result). Requires corridorRadiusM.
`earliestStartTime`	No	Only incidents starting at/after this RFC 3339 UTC time (e.g. "2026-11-02T00:00:00Z").
`functionalClasses`	No	Filter to road functional classes 1-5 (1 = motorways/major roads).
`locationReferencing`	No	Location referencing scheme(s) to include (default ["olr"]). Use ["shape"] for geometry.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 9, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations cover read-only and open-world safety, so the lower bar applies; the description adds genuine context beyond them: the default locationReferencing of ["olr"] and the size cost of ["shape"]. It also discloses a subtle truncation behavior — that limit truncates the returned list only, not the server-side match set — which an agent would otherwise misread as a total-count cap.

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?

Front-loads the action, spatial filter modes and return fields, then layers in filtering, referencing defaults and planning advice in descending priority. No sentence is filler; the trailing note about limit truncation earns its place despite being last.

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

Completeness4/5

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

Rich enough for a 14-parameter read tool with no output schema: it enumerates returned incident fields (id, type, criticality, times, road-closed flag, length, OLR) so the agent knows what it gets back. Only heading off gaps are whether spatial filter combinations are mutually exclusive and any tenant/auth prerequisites.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents every parameter including conditional pairings (at+radiusM, corridorPolyline+corridorRadiusM). The description adds meaning only for locationReferencing (default and size trade-off for shape), leaving the remaining parameters to the schema — the baseline 3 applies.

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 ("List live traffic incidents") plus the three supported spatial filters (bbox, circle, corridor) and the API version. Clearly distinguishes it from here_traffic_flow and here_route, which do not enumerate incidents.

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 explicit guidance for the HGV planning case (surface roadClosures and critical incidents first) and points to here_route avoid areas when a closure blocks a corridor. Missing an explicit statement of when not to use it (e.g. historical incidents or flow-only queries), but the conditional routing advice is concrete.

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

Deploy Server