Skip to main content
Glama
Sign In
nicglazkov

CommuteScout

by nicglazkov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

best_time_to_go

Read-only

Compare departure options by drive time, arrival forecast, and incident risk to choose when to leave or visit.

Instructions

When to leave (or visit) to beat traffic and weather, for any US trip.

Answers "what's a good time to visit X", "when should I leave for the airport", "is 5 PM bad". It checks up to 16 departures across the window and returns, for each: drive minutes for that weekday and hour (TomTom historical traffic; live too within the hour), arrival time, the NWS forecast for the arrival hour with driving hazards flagged (snow, ice, fog, thunder), and how many incidents usually start on the route that hour (CommuteScout history since July 2026).

recommended is the pick: quickest without severe weather, or with arrive_by, the latest departure that still arrives on time. summary states it in one or two sentences; departures has the whole curve if the user wants options. Times are in the origin's local time zone (time_zone).

Pair with plan_trip for what is on the road right now.

Input Schema

NameRequiredDescriptionDefault
dayNo'today' (default), 'tomorrow', a weekday name, or YYYY-MM-DD, up to 60 days out.
latestNoLatest departure to consider, e.g. '8pm'. Default 9:00 PM.
originNoAn address, landmark or place anywhere in the US, e.g. '1600 Pennsylvania Ave, Washington DC' or 'Pike Place Market'. Include city and state when you have them. 'home', 'work' or a saved place's name use the user's saved places (see get_my_places). Leave origin out to start from the user's Home.
earliestNoEarliest departure to consider, local time, e.g. '7am' or '07:00'. Default 6:00 AM.
arrive_byNoInstead of a window: the time the user must arrive, destination local time ('9am', 'tomorrow 9:00'). Returns the latest safe departure.
destinationNoAn address, landmark or place anywhere in the US, e.g. '1600 Pennsylvania Ave, Washington DC' or 'Pike Place Market'. Include city and state when you have them. 'home', 'work' or a saved place's name use the user's saved places (see get_my_places). Leave origin out to start from the user's Home.
step_minutesNoSpacing between departures checked. Default fits the window into 16.
origin_coordsNoExact 'lat,lon' instead of a place name, e.g. '47.6097,-122.3421'. Wins over the place name.
destination_coordsNoExact 'lat,lon' instead of a place name, e.g. '47.6097,-122.3421'. Wins over the place name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.132.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover readOnly and openWorld; the description supplies the real behavioral detail: up to 16 departures sampled, TomTom historical traffic plus live within the hour, NWS forecast at the arrival hour with hazard flagging, and CommuteScout incident history since July 2026. It also explains the selection logic for `recommended` and what `summary` versus `departures` contain.

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?

Front-loaded with purpose and example phrasings, then mechanics, then return shape, then the sibling hand-off. Every sentence carries information, though the data-source enumeration is slightly dense and could be tightened.

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?

With no output schema and 9 all-optional parameters, the description carries the burden well: it names the return fields (`recommended`, `summary`, `departures`), the time zone convention, the sampling cap, and the fallback to Home when origin is omitted. An agent has enough to call this correctly on the first try.

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 baseline is 3, but the description adds meaning beyond the schema by explaining that arrive_by changes the meaning of `recommended` (latest departure that still arrives on time) and that the 16-departure cap drives step_minutes defaults. Times being in the origin's local time zone is also useful framing not stated in the schema.

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 — recommends departure/visit times for a US trip — and anchors it with three sample user questions ('what's a good time to visit X', 'when should I leave for the airport', 'is 5 PM bad'). It clearly distinguishes itself from siblings by naming plan_trip as the complementary 'right now' tool.

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 concrete usage contexts (departure planning, airport timing, judging a specific hour) and explicitly routes the agent to plan_trip for current road conditions. It does not exclude or contrast with nearby siblings like get_traffic or check_route, so it stops short of full when/when-not guidance.

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

Deploy Server

Other Tools