Pod

Available as Markdown and JSON. Pod is also available over MCP.

Reported issues for noaa-marine-mcp-server

Pod holds 17 of 22 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.

Back to noaa-marine-mcp-server.

Most discussed

feat(dates): accept YYYY-MM-DD for begin_date and end_date

Use case

noaa_marine_get_tide_predictions, noaa_marine_get_water_level, and noaa_marine_get_currents declare begin_date/end_date as /^\d{8}$/, so YYYY-MM-DD fails the schema even though it names the same calendar date CO-OPS itself accepts, and most fleet date inputs use the hyphenated form — callers carry it over and hit a rejection on every date field.

Related: cyanheads/mcp-ts-core#488

Proposed behavior

Accept ^\d{8}$ or ^\d{4}-\d{2}-\d{2}$ on…

Read the thread · 2026-09-22 · closed · 3 comments

bug(time-series): 6-minute calls exceed context limits and desync text output

Server version

0.4.0

mcp-ts-core version

^0.13.3

Runtime

Node.js

Runtime version

Node 26.5.0

Transport

stdio

OS

macOS 27.0

Description

The three CO-OPS time-series tools return more data than an MCP client can safely place in context, and two of them render a different subset in content[] than they return in structuredContent.

The framework's overflow helper treats 24,000 bytes as the point past which a payload should stop being inlined…

Read the thread · 2026-08-11 · closed · 3 comments

bug(find_stations): truncation disclosure computes shown/cap/ceiling that the enrichment block never declares

Server version

0.5.1

mcp-ts-core version

^0.13.6

Runtime

Bun

Runtime version

Bun 1.4.0

Transport

stdio

Description

noaa_marine_find_stations discloses a capped result through ctx.enrich.truncated({ shown, cap, ceiling, guidance }), but its enrichment block declares only notice, applied_search, and sources. The framework strips undeclared enrichment keys at output validation, so shown, cap, and truncationCeiling are computed on every capped…

Read the thread · 2026-09-17 · closed · 2 comments

bug(get_water_level): a window before the station record is reported as verified_data_lag

Server version

0.5.1

mcp-ts-core version

^0.13.6

Runtime

Bun

Runtime version

Bun 1.4.0

Transport

stdio

Description

On the hourly, high_low, and daily_mean intervals, every CO-OPS "may not be offered at this station at the requested time" answer becomes verified_data_lag, whose recovery says to wait for CO-OPS to verify the prior month. CO-OPS sends that same sentence for a window that ends before the station's record begins. In that case no amount of…

Read the thread · 2026-09-22 · closed · 1 comment

bug(coops): CO-OPS HTTP 403 throttling surfaces as a bare fetch failure with no reason or recovery

Server version

0.5.0

mcp-ts-core version

^0.13.3

Runtime

Node.js

Runtime version

Node 26.5.0

Transport

stdio

Description

CO-OPS answers a burst of requests from one address with HTTP 403 for about two minutes. No CO-OPS request site maps that status — rethrowClassified finds no CO-OPS message in the body, and each tool's catch handles only status === 400 — so the caller gets a bare Forbidden fetch failure with no reason or recovery, which telemetry files…

Read the thread · 2026-09-17 · closed · 1 comment

feat(find_stations): state filter cannot reach CO-OPS stations the catalog publishes without a state

Use case

noaa_marine_find_stations matches state against the CO-OPS catalog row's own state, which no currentpredictions row carries and 431 of 3,499 tidepredictions rows leave blank (mdapi catalogs as of 2026-09-22). { "state": "WA", "types": ["current"] } returns total_found: 0, although for 204 of the catalog's 2,785 current stations the nearest state-bearing tide or water-level station is in Washington and within 25 km.

Proposed behavior

Resolve a state for every…

Read the thread · 2026-09-17 · closed · 1 comment

bug(get_water_level): residual_summary reports a negative max_surge or a phantom max_drawdown on one-sided windows

Server version

0.5.0

mcp-ts-core version

^0.13.3

Runtime

Node.js

Runtime version

Node 26.5.0

Transport

stdio

Description

residual_summary on noaa_marine_get_water_level takes max_surge as max(residuals) and max_drawdown as abs(min(residuals)), so a one-sided window reports an event that didn't happen: a station that sat above prediction all window gets a positive max_drawdown; one that sat below gets a negative max_surge.

Steps to…

Read the thread · 2026-09-17 · closed · 1 comment

feat(get_monthly_means): add a tool for the CO-OPS monthly_mean product

Use case

A sea-level or tidal-range trend needs CO-OPS's monthly_mean product, one verified row per station-month of tidal datums and extremes. No tool exposes it.

Related: #30

Proposed behavior

Add noaa_marine_get_monthly_means as its own tool. Its rows have no timestamp or single value, no paired prediction series, and a different range ceiling.

input: {
  station_id, begin_date, end_date, // YYYYMMDD | YYYY-MM-DD via validateCoopsDateRange
  datum,…

[Read the thread](https://github.com/cyanheads/noaa-marine-mcp-server/issues/33) · 2026-09-17 · closed · 1 comment

## Most recent

### bug(get_water_level): a window entirely in the future returns the generic no_data recovery

### Server version

0.6.0

### mcp-ts-core version

0.13.6

### Runtime

Bun

### Runtime version

Bun 1.4.0

### Transport

HTTP (Streamable HTTP)

### OS

Linux (Docker)

### Description

`noaa_marine_get_water_level` sends a window that lies entirely in the future to CO-OPS and reports the empty answer as the generic `no_data`. That recovery offers three possible causes (offline station, record starts later, future window) and leaves the caller to guess which one applies. The handler already…

[Read the thread](https://github.com/cyanheads/noaa-marine-mcp-server/issues/45) · 2026-09-24 · open · 0 comments

### feat(find_stations): return empty searches as a structured result with filter echo and notice

### Use case

When `noaa_marine_find_stations` matches nothing it throws `no_results` with one fixed hint: `Widen the search by increasing radius_km, removing type filters, or using a broader query`. The error names no filter, so the caller cannot tell which one emptied the result — and two of the six narrowing dimensions are applied without being asked for.

`{ "state": "WA", "source": "ndbc" }` is the sharpest case. `state` is CO-OPS-only, so it excludes NDBC (#5); `source: "ndbc"` excludes…

[Read the thread](https://github.com/cyanheads/noaa-marine-mcp-server/issues/31) · 2026-09-17 · closed · 1 comment

### feat(get_water_level): add hourly, high/low, and daily-mean intervals for long-range analysis

### Use case

`noaa_marine_get_water_level` returns only 6-minute observations and allows at most 31 days per call. A coastal flood analyst who needs a year of observed high waters, or a decade of Great Lakes daily means for a trend, has to make 12+ calls of about 7,400 rows each — and each of those calls already returns far more than a client can hold (#18). CO-OPS serves these views directly as [coarser products](https://api.tidesandcurrents.noaa.gov/api/prod/).

Related: #18
Depends on: #25…

[Read the thread](https://github.com/cyanheads/noaa-marine-mcp-server/issues/30) · 2026-09-17 · closed · 1 comment

### feat(find_stations): match query against CO-OPS station IDs

### Use case

A caller holding a CO-OPS station number — off a chart, a tide table, or an earlier response — cannot look it up with `noaa_marine_find_stations`. `query` matches CO-OPS rows against the station **name** only; NDBC rows match on name or ID. So the one source whose IDs are printed on public products is the source you cannot search by ID.

Two failure modes, both measured against the live catalogs on 2026-09-17 (6,348 distinct CO-OPS station IDs across the three `mdapi` lists; 1,353…

[Read the thread](https://github.com/cyanheads/noaa-marine-mcp-server/issues/29) · 2026-09-17 · closed · 1 comment

### feat(find_stations): expose the NDBC waterquality flag as a water_quality capability

### Use case

To reach sub-surface water-quality data — temperature, salinity, dissolved oxygen at depth — an agent has to guess. `noaa_marine_get_ocean_observations` tells it to: its description says sub-surface sensors "are not marked by any station-catalog flag, so no capability filter guarantees coverage", and its `observations_not_found` recovery sends the caller back to browse `source="ndbc"` and "try their IDs". The [NDBC active-stations…

[Read the thread](https://github.com/cyanheads/noaa-marine-mcp-server/issues/28) · 2026-09-17 · closed · 1 comment

### feat(get_currents): select and report the current-prediction depth bin

### Use case

Harmonic CO-OPS current stations publish predictions for several depth bins, and `noaa_marine_get_currents` can neither select a bin nor report which one it returned — so a pilot or diver planning around slack water can get timings for the wrong depth and have no way to notice.

### Proposed behavior

The `currentpredictions` catalog lists one row per bin: 4,430 rows over 2,785 distinct station IDs, with 947 stations carrying more than one bin. `PUG1515` (West Point, West of) has…

[Read the thread](https://github.com/cyanheads/noaa-marine-mcp-server/issues/27) · 2026-09-17 · closed · 1 comment

### bug(coops): valid subordinate and weak-and-variable stations fail as station errors; catalog class not surfaced

### Server version

0.4.0

### mcp-ts-core version

^0.13.3

### Runtime

Bun

### Runtime version

Bun 1.4.0

### Transport

HTTP (Streamable HTTP)

### Description

The CO-OPS station catalogs give each prediction station a class through `type`. The server drops that field, so two large groups of valid stations fail with errors that call them inactive or unknown, and nothing warns a caller in advance.

| Catalog | `type` values | Rows | Distinct station IDs |
|:---|:---|---:|---:|
|…

[Read the thread](https://github.com/cyanheads/noaa-marine-mcp-server/issues/26) · 2026-09-17 · closed · 1 comment

### bug(datum): datum enum offers invalid CD and omits accepted datums; rejections reported as station_not_found

### Server version

0.4.0

### mcp-ts-core version

^0.13.3

### Runtime

Bun

### Runtime version

Bun 1.4.0

### Transport

HTTP (Streamable HTTP)

### Description

The `datum` enum on `noaa_marine_get_tide_predictions` and `noaa_marine_get_water_level` does not match the datums [CO-OPS](https://api.tidesandcurrents.noaa.gov/api/prod/) accepts, and a rejected datum is reported as a station error.

The enum is `MLLW, MHHW, MSL, MTL, MHW, MLW, CD, STND` on both tools. Measured against the…

[Read the thread](https://github.com/cyanheads/noaa-marine-mcp-server/issues/25) · 2026-09-17 · closed · 1 comment

### bug(get_conditions): wave fields read as null because only the newest NDBC row is parsed

### Server version

0.3.2

### mcp-ts-core version

^0.13.2

### Runtime

Bun

### Runtime version

Bun 1.4.0

### Transport

HTTP (Streamable HTTP)

### OS

macOS

### Description

`noaa_marine_get_conditions` reports wave height, dominant period, average period, and mean wave direction as `null` ("not reported") on buoys that are measuring waves normally.

`parseRealtimeText` resolves every value from one row — the first non-`#` line of the realtime2 `.txt` feed. NDBC does not write every…

[Read the thread](https://github.com/cyanheads/noaa-marine-mcp-server/issues/24) · 2026-09-17 · closed · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/cyanheads/noaa-marine-mcp-server/issues).