Skip to main content
Glama

noaa-marine-mcp-server

by io.github.cyanheads

Get Water Level

noaa_marine_get_water_level
Read-onlyIdempotent

Observed water level (real-time or historical) for a CO-OPS water-level station, with paired predictions for comparison. The difference (residual = observed − predicted) indicates storm surge (positive) or anomalous drawdown (negative). Returns 6-minute observations alongside 6-minute predictions. Date range is limited to 31 days per request; split longer ranges into multiple calls. Use noaa_marine_find_stations first to resolve a station name or location to a valid station ID.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
datumNoTidal datum reference plane. MLLW (default) is the US nautical chart datum. MSL = mean sea level; MHHW = mean higher high water (flooding reference).MLLW
unitsNoUnit system: english = feet; metric = meters.english
end_dateYesEnd date in YYYYMMDD format (inclusive), e.g. "20240601".
time_zoneNoTime zone for returned timestamps. lst_ldt = local standard/daylight time (default); gmt = UTC; lst = local standard time year-round.lst_ldt
begin_dateYesStart date in YYYYMMDD format, e.g. "20240601".
station_idYesCO-OPS water-level station ID (numeric, e.g. "9447130" for Seattle). Obtain from noaa_marine_find_stations with types=["water_level"].

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
datumNoTidal datum used — echoed for correct interpretation of water heights.
errorNoPresent when the call failed. Absent on success.
unitsNoHeight units: "english" (feet) or "metric" (meters).
station_idNoStation ID echoed from the request — for chaining.
predictionsNoPaired 6-minute tide predictions for the same period. May be empty if CO-OPS predictions are unavailable for this station.
observationsNo6-minute observed water level readings.
station_nameNoStation name as returned by CO-OPS.
residual_summaryNoSummary of observed-minus-predicted residuals in the requested units. Only present when both observations and predictions are available.

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, so safety is covered. The description adds valuable behavioral details: 6-minute observation/prediction interval, the residual calculation (observed−predicted) and its interpretation for surge/drawdown, and the date range limit. These go well beyond the annotations and enrich agent understanding.

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 compact—four sentences that sequentially cover purpose, key output feature, constraint, and prerequisite. Every sentence earns its place, and the most important information (what it does) is front-loaded.

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 moderate complexity and that an output schema exists, the description covers all necessary operational aspects: station resolution, date limits, output granularity, and interpretation of residuals. Nothing critical for successful invocation is missing.

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%, so all parameters are documented (e.g., datum meanings, units, time zones). The description adds no new parameter-specific semantics; its mention of station_id from find_stations duplicates the schema. However, it does contextualize the date parameters with the 31-day limit, which provides slight value beyond the raw schema.

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 clearly states a specific resource (CO-OPS water-level station), the data type (observed water level), and the paired predictions, which distinguishes it from siblings like get_conditions or get_tide_predictions. The mention of residual analysis adds specificity to what the tool 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?

The description explicitly instructs to use noaa_marine_find_stations first, which is a clear prerequisite and usage guideline. It also provides the 31-day date range constraint and advises splitting longer ranges. However, it does not explicitly contrast with alternative tools like get_tide_predictions, though the purpose clarity covers that implicitly.

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