noaa-marine-mcp-server

Get Monthly Means

noaa_marine_get_monthly_means

Read-onlyIdempotent

Verified monthly means for a CO-OPS water-level station, one row per station-month: the month's highest and lowest water, its tidal datums (MHHW, MHW, MSL, MTL, MLW, MLLW, DTL), tidal ranges (GT, MN, DHQ, DLQ), and lunitidal intervals (HWI, LWI) — the record a sea-level or tidal-range trend over years to decades is read from. Heights are relative to the requested datum in the requested units. A value CO-OPS publishes no figure for is omitted rather than reported as zero; a Great Lakes station carries only highest, msl, and lowest. A range may span up to 73,000 days, checked before the call, and CO-OPS verifies this product monthly, for the prior month, so a window ending on or after the first day of the prior month can fail with verified_data_lag. A range whose months fit the response budget is returned whole; a longer one returns the leading months, with rows_matched, rows_returned, and next_offset reporting how many matched and which offset reaches the rest. Use noaa_marine_find_stations with types=["water_level"] first to resolve a station name or location to a station ID.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`datum`	No	Datum the monthly heights are referenced to. MLLW (default) is the US nautical chart datum; MHHW, MHW, MTL, MSL, and MLW are the other tidal planes. NAVD is NAVD88 and reads only where the station has an NAVD88 tie. STND is the station's own datum and reads any station. IGLD and LWD apply at Great Lakes stations only, which carry no tidal datum, and CRD at Columbia River stations only. A datum this station does not carry comes back as datum_unavailable.	MLLW
`limit`	No	Maximum months to return on this page, for a caller that wants fewer than the response budget allows. Omit for the largest page that fits; a value larger than the budget allows does not widen the page.
`units`	No	Unit system for the heights: english = feet; metric = meters. The lunitidal intervals are hours either way.	english
`offset`	No	Month offset into the matched series, for reading a range whose months do not fit one response. 0 (default) starts at the first month; pass the next_offset from a previous call to continue. An offset past the last month returns an empty page rather than an error.
`end_date`	Yes	End date (inclusive), YYYYMMDD or YYYY-MM-DD, e.g. "20251231" or "2025-12-31". The month it falls in is the last month returned.
`begin_date`	Yes	Start date, YYYYMMDD or YYYY-MM-DD, e.g. "19750101" or "1975-01-01". The month it falls in is the first month returned.
`station_id`	Yes	CO-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

Name	Required	Description
`datum`	No	Datum the heights are referenced to — echoed for correct interpretation.
`error`	No	Present when the call failed. Absent on success.
`units`	No	Height units: "english" (feet) or "metric" (meters).
`months`	No	One row per station-month in the requested range, oldest first — the whole matched series when it fits one response, otherwise the leading page starting at offset. rows_matched and next_offset report what a page left behind.
`notice`	No	What this page of the monthly series covers and how to reach the next page.
`end_date`	No	End of the requested range as sent to CO-OPS, YYYYMMDD.
`truncated`	No	True when this page stops short of the last matched month, so further months remain at next_offset. False on the final page and on a page past the end. Absent when the whole matched series was returned.
`begin_date`	No	Start of the requested range as sent to CO-OPS, YYYYMMDD.
`station_id`	No	Station ID echoed from the request — for chaining.
`next_offset`	No	Offset to pass as offset on the next call, or null when this page reaches the last matched month. Absent when the whole matched series was returned.
`page_offset`	No	Month offset this page starts at, echoed from the request. Absent when the whole matched series was returned.
`rows_matched`	No	Months the requested range matched, before the page was cut. Absent when the whole matched series was returned.
`station_name`	No	Station name as returned by CO-OPS.
`rows_returned`	No	Months this page carries — the length of months. Absent when the whole matched series was returned.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, so the safety profile is already known. The description adds substantial behavioral context beyond that: CO-OPS verifies monthly for the prior month so recent windows can fail with verified_data_lag; omitted values are omitted rather than zeroed; Great Lakes stations carry only highest/msl/lowest; ranges up to 73,000 days are checked before the call; pagination behavior with rows_matched/rows_returned/next_offset. This is rich, non-obvious behavior that an agent needs to know.

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 dense but every sentence earns its place. It front-loads the core purpose and data shape, then covers edge cases (Great Lakes, omitted values, verified_data_lag), then pagination, then the prerequisite sibling call. No fluff, no repetition of schema content. It's long but appropriately so for a complex tool with 7 parameters and non-obvious behavior.

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 (7 params, 3 required, 2 enums, output schema present), the description covers everything an agent needs: what the data is, how to get the station ID, what can fail, how pagination works, and how units/datums behave. The output schema exists so return values don't need to be spelled out. The only minor gap is not listing the exact output fields, but the output schema covers that.

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 schema already documents all 7 parameters thoroughly. The description adds value by explaining the datum semantics (heights relative to requested datum), the units (english=feet, metric=meters), and the pagination semantics (offset, next_offset). It also clarifies that a datum the station doesn't carry returns datum_unavailable. However, most parameter meaning is already in the schema, so the description's marginal contribution is moderate but real.

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 monthly means'), a specific resource ('CO-OPS water-level station'), and the exact data shape ('one row per station-month... highest and lowest water, tidal datums...'). It clearly distinguishes this from siblings like noaa_marine_get_water_level (which presumably returns raw water level readings) and noaa_marine_get_tide_predictions (predictions vs verified means). The phrase 'Verified monthly means' and 'the record a sea-level or tidal-range trend over years to decades is read from' makes the purpose unmistakable.

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?

The description explicitly says to use noaa_marine_find_stations with types=["water_level"] first to resolve a station name to a station ID. It also explains when the tool will fail (verified_data_lag for windows ending on/after the first day of the prior month) and how pagination works (rows_matched, rows_returned, next_offset). This is explicit when-to-use guidance with a named alternative.

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 tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.