Skip to main content
Glama

Weather along your route

plan_route
Read-onlyIdempotent

Weather and a flyover for a GPX file or route the user shares. If the user attached a GPX or route file, call plan_route and pass the file as gpx_file; if you can read the file's contents yourself, you may instead pass its text as gpx or its points as points. Never treat a file name as an event name. Also a Ride with GPS or GPX link, or another app's route points: the weather along it at the time they'd ride or run it, and a flyover of the route (a flyby, fly over my route) that plays in the chat, coloured by the weather: the forecast within 10 days, 10 years of weather on that date beyond it, rated by Windline's forecast engine, with the headwind and tailwind stretches, heat and rain. No account needed. For "What will the wind be like on this route on Saturday at 6?" or "Show me the weather for this GPX and a flyover". The route stays theirs: nothing is published. For a 3D flight and a route video, offer to save it as a private ride or run with create_event (visibility private). Several GPX files are one multi-day tour: pass them all as files (ordered by the numbers in their names, else by the map; one day after another from start), never one call per file. A route can also come from another app's tool as its points or an encoded polyline (for example a route or activity map from a fitness app): pass it as polyline or points. Never ask the user to export a GPX if you already have the route's points.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "start": "<start>"
    },
    "name": "plan_route"
  }
}

Input Schema

NameRequiredDescriptionDefault
tzNoThe route's IANA time zone, if known (else worked out from where it starts).
gpxNoThe GPX file's text (up to 5 MB): if the user pasted it, or attached a file you can read yourself (for example with code).
urlNoA link to the route: a Ride with GPS route, ride or collection (a collection gives one day per route), or any public link to a GPX file. Not Strava.
nameNoWhat to call the plan, if the user named it.
paceNoRiding speed in km/h (default 25), or running pace in minutes per km (default 6).
filesNoSeveral GPX files (a multi-day tour): ordered by the numbers in their names, else by the map; one day after another from start.
sportNoride (default) or run.
startYesWhen they start, "YYYY-MM-DD HH:MM" local to the route. Ask if they didn't say.
unitsNoPass the asker's units: imperial for users in the US, UK road distances, Liberia or Myanmar, or when they ask in miles/°F; otherwise metric.
pointsNoThe route as its points: [[lat, lon], …], with elevation in metres as a third number if known. Up to 50,000. Use it for points another app's tool gave, or that you read from an attached file (GPX, FIT, TCX) with code.
startsNoEach day's own local start, "YYYY-MM-DD HH:MM", when they differ.
gpx_fileNoThe GPX or route file the user attached (ChatGPT passes it here).
polylineNoThe route as an encoded polyline (Google's format, precision 5 or 6), as another app's tool gives it (a route's or an activity's map).
gpx_filesNoSeveral GPX or route files the user attached (ChatGPT passes them here): one per day of a tour, ordered by the numbers in their names, else by the map.
rest_daysNoWith files: dates with no riding, "YYYY-MM-DD", only if the user named rest days.

Output Schema

NameRequiredDescriptionDefault
kmNoThe route's length in km.
tzNoThe route's IANA time zone.
urlNoThe event's page.
daysNoEach day: name, date (ISO), basis, rating (good, fair, tough), why, start_temp_c, finish_temp_c, effort_pct (cycling), heat_stress and wbgt_c (running), rain_mm or rain_days_in_10 and usual_high_c.
viewYesWhat this answer is; "none" when there is nothing to show (see message).
basisNoforecast (Apple Weather, within 10 days), historic (10 years of Copernicus ERA5 on that date) or mixed.
errorNoWhen the call failed: what went wrong, in words for the user.
eventNoThe event's name.
filesNoSeveral files: the file of each day, in order.
orderNoSeveral files: how the days were ordered (numbers, map or upload).
sportNocycling or running.
unitsNo
eventsNoSeveral events matched: their names. Ask the user which one.
fly_3dNoA link to the full 3D flight, only for a route with a public page; else null.
signupNoWithout a sign-in: { label, url } to make a free Windline or RunFast account (?ref=mcp).
flyoverNoThe map flies over the route in the chat.
messageNoWhen view is "none": what to tell the user (no match, not live yet, a question back).
timed_forNoWhat the times assume (the start, the pace).
order_noteNoWhen the file numbers and the map disagree: what was chosen.
sponsor_lineNoThe line every answer ends with: who brings livedot's live tracking free.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/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), and the description adds real context beyond them: no account required, the route is not published, forecast is bounded to 10 days with historical weather up to 10 years back, and the rating comes from Windline's forecast engine. It never describes latency, rate limits, or failure behavior when a GPX is malformed, keeping it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Almost every clause carries useful information, but they are packed into one rambling multi-clause block with stacked parentheticals ('a flyby, fly over my route', 'for example a route or activity map from a fitness app'). The purpose is not cleanly front-loaded and the structure makes it hard to scan.

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?

With an output schema present, return values need no explanation, and the description covers the hard parts of a 15-parameter tool: all input channels, multi-day tours, rest days, and the handoff to create_event. The gaps are minor, mainly failure handling for bad files and the unresolved overlap with fly_route.

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 decision-level semantics the schema does not: which input channel to choose (gpx_file vs gpx vs points vs polyline), that file names drive day ordering, and the warning to never treat a file name as an event name. These choices guide selection between the 15 mutually-exclusive-looking parameters, so it edges above baseline.

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?

The opening states a specific verb+resource combination: weather plus a flyover for a GPX file or shared route, and it names the concrete artifacts (headwind/tailwind stretches, forecast within 10 days). It falls short of 5 because it never distinguishes itself from the sibling fly_route, whose name implies the same flyover capability, leaving the agent to guess which tool owns the flyover.

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?

Rich conditional guidance: use gpx_file for attachments, gpx/points if the agent can read the file itself, all files in one call for multi-day tours (never one call per file), polyline for another app's route, and explicitly route the save-as-private-step to create_event. It does not tell the agent when to prefer plan_route over the sibling event_weather or fly_route, so tool selection among siblings remains inferred.

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.