Skip to main content
Glama

Surf forecast

surf_forecast
Read-onlyIdempotent

Live 7-day surf forecast for a surf town and each of its spots, rated hour by hour for that spot (rating Flat, Poor, Fair, Good, Great or Epic with a 0–10 score and the reasons why, from the way the spot's coast faces, the swell trains, their period and the wind against the coast): per day the rating, the best time window (best.from–best.to, local time, which already accounts for the tide), what to expect in surfers' words (body: 'Chest to head high', surface: Glassy/Clean/Fair/Bumpy/Choppy/Blown out), breaking surf height (surf [min, max] m), wave height range, swell height, period and direction, wind, high and low tides with heights (predicted from the nearest tide gauge: see tide, or approximate from the ocean model where there is none), sunrise/sunset, water temperature (the ocean model's, set to the newest satellite measurement at the town: water says how, with source 'satellite' and the satellite's day, 'climate' when only this month's measured difference was used, or 'model'; months: the measured mean by month) and confidence (high/medium/low: three wave models compared, ECMWF, Météo-France and NOAA, with their figures in models; a model the town's buoy has shown to be far off there is left out), and, when the models differ on a day's size by 20% or more, range (wave [min, max] m at sea, surf [min, max] m at the spot, body in surfers' words); the town's days name the best spot (bestSpot). accuracy, where the town has a buoy (NOAA, Queensland Government, E.U. Copernicus Marine or Israel Oceanographic & Limnological Research): how often the forecast was within 20% of it over the last weeks, whether sizes are corrected for the model's bias there (method 'ratio', or 'power' with fit { k, beta }: the correction depends on size), at which spots (correctedSpots: those facing the same sea as the buoy), the swell period's record and correction (period: within15 is the share of hours within 1.5 s, offset the seconds added), each wave model's own record at the buoy (models: { n, mae, within20 }), the closest one (bestModel) and the ones left out of the confidence check (unreliable). offshore, for every town: the open water off the town checked against the satellite altimeters' passes (Copernicus Marine, within 100 km; passes, km, from/to, within20 and within20Raw, ratio satellite ÷ model, corrected: whether sizes here are scaled by it, which happens only where no buoy correction applies, models/bestModel/unreliable offshore, and the credit line to show). updated says when the forecast was worked out (it is cached for up to 3 hours). Plus the next 48 hours every 3 hours, now (rating, why, tide rising/falling, and water: this hour's sea temperature in °C, set to the satellites like the days'; trust it as measured only where water.source is 'satellite' or 'climate', as the town page does) and live: what the nearest buoy or wave station, the newest satellite altimeter pass near the town (satellite: mission, time, km out, wave height, and what the model said there and then) and the airport wind report (METAR) measure right now, checked against the forecast (check: on-track, bigger/smaller, windier/calmer; check.factor is the nudge applied to today's sizes, from the buoy, or from the satellite where there is no buoy). When it is not 1, nowcast says so and today's surf and body (now, hours, today's day) are already scaled toward the measurement, as on the site; ratings stay the model's. Waves from Open-Meteo Marine, wind from MET Norway.

Input Schema

NameRequiredDescriptionDefault
spotNoOptional: one spot name from get_town.
townYesTown slug, e.g. "ericeira".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Beyond the supplied annotations, the description discloses that results are cached for up to 3 hours, names the underlying wave and wind data sources, explains confidence methodology across three models, and describes nowcast scaling and caveats about trusting water temperature only when the source is satellite or climate. This is substantial behavioral context that annotations alone do not provide.

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

Conciseness2/5

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

The description is front-loaded with the main purpose, but it then becomes an extremely dense, semicolon-heavy block with deeply nested parenthetical detail. Much of the output detail is useful because there is no output schema, but the structure is difficult to parse and would benefit significantly from breaking the material into shorter sections.

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?

Given the tool's complexity and the absence of an output schema, the description is remarkably complete: it explains forecast fields, confidence and model comparison, accuracy and buoy correction, offshore satellite checks, now, live observations, and nowcast scaling. An agent has enough context to understand what the tool returns and how to interpret the caveats.

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%, and the schema already defines town as a town slug and spot as an optional spot name from get_town. The description adds little parameter-specific guidance beyond reinforcing that forecasts cover a town and each of its spots, so the high-coverage baseline of 3 is appropriate.

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?

The description opens with a specific verb and resource: 'Live 7-day surf forecast for a surf town and each of its spots, rated hour by hour.' It clearly distinguishes this forecast tool from current-condition siblings like surf_now and surf_cams by emphasizing the 7-day outlook and per-spot hourly ratings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied by 'Live 7-day surf forecast' and the forecast-vs-now distinction is clear in context, but the description never explicitly says when to use this tool versus surf_now, surf_cams, or find_surf_spots. It also does not state that the optional spot should come from get_town, leaving that to the schema.

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