Skip to main content
Glama

noaa-marine-mcp-server

by io.github.cyanheads

Get Marine Conditions

noaa_marine_get_conditions
Read-only

Live marine conditions from an NDBC buoy: wave height/period/direction, wind speed/gust/direction, sea-surface temperature, air temperature, barometric pressure, and dew point. All values are SI units — wind in m/s, wave height in m, pressure in hPa, temperatures in °C. Exceptions: TIDE is in feet and VIS is in nautical miles (rarely populated at offshore buoys). Numeric fields are null when the buoy sensor did not report a value — this is normal for offshore buoys. Observations are updated approximately every 10 minutes; data may be 10–20 minutes old. Use noaa_marine_find_stations with source="ndbc" and types=["met"] to find station IDs near a location — met-flagged stations are the ones most likely to serve live conditions. Roughly a third of active NDBC stations report neither meteorological nor current data, and most of those have no observation file, so omitting the types filter will surface station IDs this tool cannot read.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
station_idYesNDBC buoy station ID (5-character alphanumeric, e.g. "46041" for Cape Elizabeth). Obtain from noaa_marine_find_stations with source="ndbc" and types=["met"].

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
sourceNoData source — always "ndbc" for this tool.
tide_ftNoTide height in feet. NOTE: always in feet regardless of other unit settings. Rarely populated at offshore buoys. Null if not reported.
latitudeNoStation latitude in decimal degrees.
longitudeNoStation longitude in decimal degrees.
air_temp_cNoAir temperature in °C. Null if not reported.
station_idNoStation ID echoed from the request — for chaining.
dew_point_cNoDew point temperature in °C. Null if not reported.
observed_atNoISO 8601 UTC timestamp of the observation row used.
pressure_hpaNoAtmospheric pressure in hPa. Null if not reported.
station_nameNoStation name from the NDBC active stations list.
water_temp_cNoSea-surface temperature in °C. Null if not reported.
gust_speed_msNoWind gust speed in m/s. Null if not reported.
wave_height_mNoSignificant wave height in meters. Null if not reported.
wind_speed_msNoWind speed in m/s. Null if not reported.
visibility_nmiNoVisibility in nautical miles. NOTE: always in nautical miles regardless of other unit settings. Null if not reported.
average_period_secNoAverage wave period in seconds. Null if not reported.
wind_direction_degNoWind direction in degrees true (0–360). Null if not reported by the buoy.
dominant_period_secNoDominant wave period in seconds. Null if not reported.
mean_wave_direction_degNoMean wave direction in degrees true. Null if not reported.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true and openWorldHint=true; the description adds significant behavioral context: unit conventions (SI except TIDE/VIS), the possibility of null values as normal (sensor non-reporting), the ~10-minute update cadence with potential 10–20 min staleness, and the note that many NDBC stations lack data. No contradiction and rich beyond what annotations convey.

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

Conciseness5/5

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

The description is structured logically: core data first, then units, then nulls and staleness, then usage guidance. Every sentence contributes new information—no filler. It is appropriately sized for the tool's complexity and front-loads the most critical facts.

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 has an output schema (so return structure is documented elsewhere) and one parameter with full schema coverage, the description comprehensively covers the non-obvious context: unit exceptions, null behavior, freshness, and station-finding prerequisites. An agent can call this tool correctly with no gaps.

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?

The single parameter station_id has complete schema coverage (100%), so the baseline is 3. The description reinforces the schema's guidance by explaining how to obtain valid station IDs via the find tool and why 'met' type matters, adding practical value beyond the schema alone.

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 states a specific verb ('get'), a specific resource ('live marine conditions from an NDBC buoy'), and enumerates the exact measurements returned. It clearly differentiates from siblings by its focus on real-time buoy observations rather than forecasts or other marine data.

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

Usage Guidelines5/5

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

It explicitly instructs to first use noaa_marine_find_stations with source='ndbc' and types=['met'] to obtain station IDs, and warns that omitting the types filter will yield IDs this tool cannot read. This gives clear when-to-use guidance and a key prerequisite, leaving no room for misinterpretation.

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

All noaa-marine-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: station discovery, live buoy conditions, NDBC current profiles, CO-OPS tidal current predictions, tide predictions, and water levels. The descriptions explicitly differentiate similar-named tools (e.g., get_currents vs get_current_profile), leaving no ambiguity.

Naming Consistency5/5

All tool names follow a consistent 'noaa_marine_verb_noun' pattern using snake_case. Verbs are descriptive (find, get) and nouns specify the data (stations, conditions, current_profile, etc.). No mixing of styles or abbreviations.

Tool Count5/5

With 6 tools, the server covers the essential operations for NOAA marine data: one discovery tool and five data retrieval tools covering conditions, currents (two types), tides, and water levels. This is well-scoped for the domain—neither too sparse nor overwhelming.

Completeness4/5

The tool set covers core marine data retrieval (discovery, buoy conditions, current profiles, tidal currents, tide predictions, water levels). Minor gaps exist, such as the absence of CO-OPS current observations (only predictions) or NDBC wave spectra, but the main workflows are supported.

Resources