Skip to main content
Glama
Sign In

commutescout

by io.github.nicglazkov
OverviewDiscussionsAdmin

best_time_to_go

Read-only

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. Added

TDQS

A4.6/5.0
Behavior5/5

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

Far exceeds the annotations (which only cover readOnly and openWorld): it discloses the 16-departure cap, data sources per departure (TomTom, NWS hazards, CommuteScout history), how recommended is chosen (quickest without severe weather, or latest arrival if arrive_by set), and time-zone handling.

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 the core purpose in the first sentence and organized into useful blocks. Slightly long and prose-heavy, but nearly every sentence carries distinct return-value or behavior detail.

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 complex 9-param tool with no output schema, the description fully explains the return shape (recommended, summary, departures, per-departure fields, time_zone) and the selection logic, so an agent has what it needs to interpret results.

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, but the description adds real meaning: it explains that step_minutes fits the window into 16 departures and clarifies the arrive_by mode interplay with earliest/latest and the recommended pick.

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+resource ('when to leave/visit to beat traffic and weather') and gives concrete example questions it answers. It also distinguishes itself from plan_trip, so an agent can route between them without opening schemas.

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?

Provides concrete when-to-use examples ('what's a good time to visit X', 'when should I leave for the airport') and names plan_trip as the live-state alternative. Lacks an explicit 'don't use this for X' exclusion, but the context is otherwise clear.

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

All commutescout toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources