navigation-status

Report navigation status

A read-only request: tell the user whether navigation is running and, when asked, the route details (waypoints, distances, durations, ETA). This is answered from a single read of the navigation state — set the detailed flag appropriately on that one call and reuse the result. The twist: the state-read tool may be absent, so the active route cannot be read at all.

When this applies

"Is navigation running?", "what's my current route?", "how far / how long to go?", "where's my next stop?" — a read-only status and details request. (To start a route, change the destination, or edit a stop, see the other navigation skills.)

Tools

• get_current_navigation_state({detailed_information}) — read whether navigation is active and, with the detailed flag on, the full route details (waypoints, distances, durations). May be the missing tool — then you cannot read or verify the active route.

Method

1. Call get_current_navigation_state once, with the detailed flag set appropriately. If the user asks (or even hints) about the route — destination, waypoints, distance, duration, ETA — set detailed_information:true on the first call so a single read covers both "is it running?" and the details. When unsure whether a details follow-up is coming, default to detailed_information:true: it answers the bare "is it on?" too and saves a second call.
2. Answer both questions from that one result — active/inactive status and any route details — without redundantly re-calling.
3. Present details at the right level. For an active route, give the destination and, when detailed, the route's distance, duration, and name_via; per policy surface toll-road info when you describe a route; note the waypoint order/count for a multi-stop route. Keep it concise and speakable (this is voiced), then stop.

Ask vs. infer

• A status request is rarely ambiguous — read and answer. Don't ask the user to narrow it; the one detailed read gives you everything to answer status and details.
• Set the detailed flag from the request. If details are clearly wanted, read with detailed_information:true once; don't read with it off and then make a second redundant call to get the details.
• Re-read only when the state genuinely changed. Re-calling to fetch detail the first read already returned is the mistake. A fresh read to confirm the state after something altered it (a route was just set, a waypoint added) is legitimate — answer from that single fresh read and don't loop further.