Skip to main content
Glama

Weather along a route

route_weather
Read-onlyIdempotent

What weather you will meet as you move along a route, at the moment you reach each part of it. Not "the weather on the trail" but "what will I encounter, where, and when". Accepts a known trail_id, a GPX file, GeoJSON, an encoded polyline, coordinates, or place names. With a start_time and a pace it works out when you reach each checkpoint, reads the forecast for that place at that time, and reports what changes: rain starting, the cold coming in, the light going. For someone already out there, pass progress (how far they are, or where) and it answers for the rest of the route from now. Returns checkpoints with arrival time, place, weather and light, the changes, and a bottom line. Use get_trail_weather for an hour-by-hour timeline and clothing advice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gpxNoThe text of a GPX file (track points). Up to about 450 KB.
paceNoHow fast the person moves, as a value and a unit.
unitsNoimperial (F, mph, inches) or metric (C, km/h, mm). Defaults to imperial in the United States and metric elsewhere.
geojsonNoGeoJSON as an object or a string: a LineString, MultiLineString, or Features holding them. Longitude first, as GeoJSON has it.
activityNoWhat the person is doing, if known. One of: walking, hiking, trail_running, road_running, cycling, camping, hunting, fishing, yard_work, construction, painting_finishing, general_outdoor. Plain words work too ("run", "hike", "stain the deck"). "Running" with no more words is treated as road_running.
polylineNoAn encoded polyline (Google format).
progressNoFor someone already on the route: how far along they are right now. The answer is for the rest of the route, starting now. Give distance_miles or distance_km, or a latitude and longitude. The position is used for this answer only and is never stored or logged.
trail_idNoA trail we know by name. Call list_trails to see them. Use this OR one of the route formats below.
intensityNoHow hard the effort is, which changes what to wear. Defaults to the usual effort for the activity.
waypointsNoTwo to twelve places to travel between, each a name like "Glenbeulah, WI" or { "latitude": 43.79, "longitude": -88.05 }. They are joined by straight lines, so distances are approximate.
start_timeNoWhen the trip starts. Defaults to now. Ignored when progress is given. An ISO 8601 time such as 2026-10-03T18:00:00-05:00 (read in the place's own time zone when it has no offset), or plain words: "now", "tonight", "tomorrow morning", "Saturday", "6 PM", "between 6 PM and midnight". A bare hour with no AM or PM is refused rather than guessed.
coordinatesNoA list of [latitude, longitude] pairs, latitude FIRST.
preferencesNoOptional: { "feel": "runs_cold" | "runs_warm", "avoid": ["shorts"] }.
out_and_backNoTrue if the route is walked out and then back along the same line.
polyline_precisionNoDigits of precision in the polyline. 5 is usual, 6 is what some routers send.
total_duration_hoursNoInstead of a pace: how long the whole trip is expected to take. The pace is worked out from the length of the route.
break_minutes_per_hourNoMinutes of stops per hour of moving, which stretches arrival times.
rest_at_turnaround_hoursNoHours spent resting at the turn of an out-and-back (a night's sleep, say).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered; the description goes further with real behavior: progress position is never stored or logged, start_time is ignored when progress is given, a bare hour is refused rather than guessed, GPX input is capped near 450 KB, and units default by region. These are non-obvious traits an agent cannot infer from structured fields.

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 and the routing decision before any parameter talk, and the return summary and sibling pointer come last. The quoted 'Not "the weather on the trail" but...' sentence is rhetorically useful but slightly padded against an otherwise dense, well-ordered description.

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 an 18-parameter, zero-required, nested-input tool with no output schema, the description covers the input modes, the two execution modes, timing semantics, and even the return shape (checkpoints with arrival time, place, weather and light, the changes, and a bottom line). Nothing essential for correct invocation 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 100%, so the baseline is 3, but the description adds meaning the schema cannot: it enumerates the mutually exclusive route-input families (trail_id, GPX, GeoJSON, polyline, coordinates, place names) and states that trail_id is used OR one of the route formats. It also explains the pace-vs-total_duration_hours relationship and how break/rest inputs stretch arrival times.

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 — weather encountered along a route at each checkpoint's arrival time — and sharpens it with the contrast between 'the weather on the trail' and 'what will I encounter, where, and when'. It also names the sibling get_trail_weather and the condition that selects it, so an agent can route between them 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 Guidelines4/5

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

Explicitly covers two usage modes: a planned trip (start_time + pace) and a person already on the route (progress, answering for the remainder from now). It routes to get_trail_weather for an hour-by-hour timeline. It doesn't distinguish itself from other siblings like find_best_weather_window or outdoor_activity_weather, so it stops short of full when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources