Skip to main content
Glama

Weather MCP Server by Meteosource

get_weather_history

Historical weather (archive) with server-side aggregation.

The archive holds 20 years, but how much of it a key may read depends on
its plan: startup includes the last 7 days, standard the last year,
premium and flexi all 20 years; byvalue reaches 366 days back and no
further. Older days need Meteosource's paid historical add-on (billed per
location and day); without it the API refuses such a day with "not
allowed to access historical data this old", reported per location, so
start inside the plan's range. Dates are YYYY-MM-DD, inclusive.
Granularity: 'hourly' (raw hours, max 14 days per call), 'daily'
(per-day min/max/avg/sum statistics, max 366 days) or 'monthly'
(folded from daily, max 366 days per call — call repeatedly for
multi-year analyses; results are cached so repeats are cheap).
Variables (default: temperature, precipitation, wind): cape, cloud_cover,
dew_point, evaporation, feels_like, humidity, irradiance, ozone,
precipitation, precipitation_type, pressure, soil_temperature,
surface_temperature, temperature, weather, wind, wind_distribution.
Aggregations per variable: temperature min/max/avg, precipitation sum,
wind speed avg + gusts max, irradiance sum in Wh/m2 (useful for PV
analysis), weather = most frequent code of the day, precipitation_types =
kinds seen that day (e.g. "rain,snow"; "none" when dry) — use weather and
precipitation_type to document what happened (snow, fog, thunderstorm).
wind_distribution (daily/monthly; for wind-turbine siting) = hours per
10 m wind-speed bin (wind_hours_0_2 … wind_hours_10_plus) and
wind_power_density_w_m2 = 1/2 * 1.225 * mean(v^3) at 10 m — scale to hub
height yourself (the API has no hub-height wind).
`normals=true` (daily/monthly) adds long-term columns for each calendar
day: temperature_normal_avg/min/max, temperature_record_min/max,
wind_normal_speed, wind_record_gusts, precipitation_normal_sum and
precipitation_normal_probability — compare a period with its normal in
one call. Each location+day costs one API request on first fetch;
a single call is capped at 400 location-days — split longer ranges
into multiple calls. Not available on the free tier (startup+).

Output: `columns` once at the top level; each location has `rows` as
arrays in column order (a year of daily rows is ~15 kB).

Input Schema

NameRequiredDescriptionDefault
unitsNometric
date_toYes
normalsNo
timezoneNoauto
date_fromYes
locationsYes
variablesNo
granularityNodaily

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

No annotations exist, so the description carries the full behavioral burden and does so: plan-based read limits, the exact error string for blocked old days reported per location, per-location-day billing, first-fetch request cost, caching of repeats, a 400 location-day call cap, max ranges per granularity, and rough response size. This is exactly the operational context an agent needs before invoking.

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 a single-line summary, then organized into access, granularity, variables/aggregations and output blocks. It is long but dense; a few clauses (e.g. the wind_power_density formula, repeated caps) could be trimmed without losing decision-relevant information.

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 an 8-parameter tool with no annotations and no output schema, the description is nearly complete, even sketching the return shape (top-level 'columns', per-location 'rows', ~15 kB for a year of daily data). The remaining gap is the unexplained units/timezone parameters and no explicit statement of the default units.

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 description coverage is 0% for top-level params, so the description must compensate and largely does: date format and inclusivity, granularity values with their caps, the full variables list with defaults, and the normals=true semantics. However, 'units' and 'timezone' are never explained in either schema or description, leaving two parameters undocumented.

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?

Opens with a specific verb+resource: 'Historical weather (archive) with server-side aggregation.' It is unambiguous that this is the retrospective/archive tool versus the forecast-oriented siblings, and the granularity/aggregation framing tells the agent exactly what kind of data it returns.

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: plan-based access windows (startup 7 days, standard 1 year, premium/flexi 20 years, byvalue 366 days), the paid add-on for older days, per-granularity call caps, and when to split long ranges. It does not explicitly name a sibling alternative (e.g. get_forecast for future data), so it stops short of full when-not/exclusions 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.