Skip to main content
Glama

Weather That Doesn't Suck

by com.weatherthatdoesntsuck
OverviewDiscussionsAdmin

Weather on a trail

get_trail_weather
Read-onlyIdempotent

Weather for a trail over time, sampled along the trail rather than at one point: starting conditions, how the temperature changes through the trip, rain windows, wind and gusts, humidity and dew point, wind chill and heat index, sunrise, sunset, twilight, the moon, significant changes, alerts, and what to wear and carry. Give a trail_id (call list_trails) or the route itself, plus start_time and a pace or total_duration_hours. Returns a timeline every two hours and a bottom line. It does not know the terrain, shade or exposure unless the trail record says so, and it says that.

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. 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.
step_hoursNoHours between timeline rows. Default 2.
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

A3.6/5.0
Behavior3/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds useful context: it returns a two-hourly timeline plus a bottom line, and it flags that it does not know terrain/shade/exposure and says so. It does not discuss rate limits, auth, or cost.

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-loads the purpose in the first clause, then enumerates outputs and inputs. The long output enumeration is dense but earns its place given there is no output schema; the only mild cost is a slightly run-on feel.

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?

For a 19-parameter, no-output-schema tool, the description covers input modes, temporal coverage, timeline granularity, and caveats well. Return-format explanation is necessarily present since no output schema exists, and the coverage is adequate though it does not discuss missing-data or error behavior.

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 description coverage is 100%, so the schema already documents all 19 parameters in detail. The description adds only marginal framing, restating the trail_id-or-route choice and the pace-or-duration choice that the schema already spells out. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("weather for a trail over time") and immediately distinguishes the sampling model from a point forecast ("sampled along the trail rather than at one point"). It is clear what the tool produces, though it never names the very similar sibling route_weather, so the agent must infer that distinction.

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 entry conditions: supply trail_id (routing to list_trails) or a route, plus start_time and either a pace or total_duration_hours. It also states a limitation (no terrain/shade/exposure knowledge). It stops short of explicit when-not guidance or naming an alternative tool for point forecasts.

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

All Weather That Doesn't Suck 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