Skip to main content
Glama

weather_along_route

Forecast weather along a route, each sample read for the hour you actually reach it rather than the weather right now. Pass the route's shape (an encoded polyline6, the route tool's geometry_polyline6), optional depart_at (RFC 3339, default now), the route's duration_s (from route; omitted, an 80 km/h average is assumed and duration_source says so) and optional sample_interval_m (default 25,000, 5,000 to 100,000, at most 40 samples). Each sample carries its ETA, temperature, rain, snowfall, precipitation type and probability, wind and gust speed, visibility, the WMO weather code and severe (thunderstorm and heavy precipitation codes only). It is a FORECAST, not an observation: read on a 0.05 degree grid (about 5.5 km) at the nearest hour, up to 16 days ahead, and samples past that horizon or without data come back available: false with a reason, never painted dry. summary is one sentence (where rain or snow starts and for how far, the strongest gust, samples without data) and always ends by saying it is advisory, never a routing guarantee: keep that qualifier when you pass it on. Requires the MapMap gateway; a deployment without a weather source answers a clear error. Display the returned attribution with the forecast, linked to attribution_url, with licence_url (CC BY 4.0) linked; derived_fields names the sample fields MapMap derives rather than Open-Meteo supplies.

Input Schema

NameRequiredDescriptionDefault
shapeYesThe route shape as an encoded polyline6 (the `route` tool's `geometry_polyline6`).
depart_atNoDeparture time, RFC 3339 (e.g. "2026-10-12T14:00:00Z"); defaults to now. Forecasts reach about 16 days ahead; samples past that answer unavailable.
duration_sNoThe route's duration in seconds, used to work out when you reach each sample. Pass the `route` tool's duration; omitted, a generic 80 km/h average is assumed and `duration_source` says so.
sample_interval_mNoDistance between samples in metres (default 25,000, clamped to 5,000 to 100,000; at most 40 samples per route).

Output Schema

NameRequiredDescriptionDefault
samplesYesRoute samples, start to end.
summaryYesOne honest sentence describing the samples: where rain or snow starts and for how far, the strongest gust, how many samples had no data. Always ends by saying it is an advisory forecast, never a routing guarantee.
depart_atYesThe departure time actually used, RFC 3339 UTC.
duration_sYesThe route duration actually used, seconds.
attributionYesData attribution (CC BY 4.0): display it with the forecast, verbatim.
licence_urlYesThe data licence to link with the credit (CC BY 4.0).
severe_aheadYesTrue when any available sample carries a severe WMO code.
derived_fieldsYesThe sample fields MapMap derives rather than reads from Open-Meteo ("precipitation_type", "severe"), so a display can indicate the changes the licence asks to be indicated.
attribution_urlYesThe link the credit carries ("https://open-meteo.com/"): Open-Meteo's licence asks for it next to any place its data is displayed.
duration_sourceYes"provided" or "estimated_default_speed" (an 80 km/h guess: treat the ETAs as approximate).
sample_interval_mYesThe sample spacing actually used, metres (may be coarser than asked on a long route).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedOutput schema / properties / attribution / description
      Previous value: -"Data attribution (CC BY 4.0): display it with the forecast."New value: +"Data attribution (CC BY 4.0): display it with the forecast,\nverbatim."
    • addedOutput schema / properties / attribution_url
      Added value: +{
      +  "description": "The link the credit carries (\"https://open-meteo.com/\"): Open-Meteo's\nlicence asks for it next to any place its data is displayed.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / derived_fields
      Added value: +{
      +  "description": "The sample fields MapMap derives rather than reads from Open-Meteo\n(\"precipitation_type\", \"severe\"), so a display can indicate the\nchanges the licence asks to be indicated.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / licence_url
      Added value: +{
      +  "description": "The data licence to link with the credit (CC BY 4.0).",
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "samples",
      -  "depart_at",
      -  "duration_s",
      -  "duration_source",
      -  "sample_interval_m",
      -  "severe_ahead",
      -  "summary",
      -  "attribution"
      -]New value: +[
      +  "samples",
      +  "depart_at",
      +  "duration_s",
      +  "duration_source",
      +  "sample_interval_m",
      +  "severe_ahead",
      +  "summary",
      +  "attribution",
      +  "attribution_url",
      +  "licence_url",
      +  "derived_fields"
      +]
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: forecast-not-observation semantics, 0.05 degree grid (~5.5 km) at nearest hour, 16-day horizon, samples returned `available: false` with a reason (never painted dry), a mandatory advisory qualifier, gateway dependency with a clear error when no weather source exists, and attribution/licence display obligations. This is exactly the behavioral context an agent needs beyond the schema.

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?

Purpose and the key 'hour you reach it' distinction are front-loaded, and every sentence carries novel information with little waste. It is dense and long, with several clauses chained per sentence, but not padded.

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?

Despite high tool complexity, the description covers inputs, output fields, failure modes, licensing and safety qualifiers. Since an output schema exists, the description is not obligated to enumerate returns, yet it still gives enough for correct invocation and downstream handling.

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 coverage is 100%, so the schema already documents all four parameters including defaults, clamping and the duration fallback. The description restates the same details (80 km/h assumption, interval range, 40-sample cap) rather than adding new meaning, so the baseline 3 applies.

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 ('Forecast weather along a route') and immediately distinguishes the semantics: each sample is read for the hour you reach it, not current conditions. An agent can differentiate it from siblings like route_observations and search_along_route 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?

It makes the pipeline explicit by requiring the `route` tool's geometry_polyline6 and duration_s as inputs, and contrasts forecast vs observation. However, it never names an alternative tool or states when this should be chosen over one, leaving that to inference.

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