Skip to main content
Glama

noaa-marine-mcp-server

by io.github.cyanheads

Get Ocean Observations

noaa_marine_get_ocean_observations
Read-only

Live sub-surface oceanographic observations from an NDBC station's water-quality sensors: at each reported depth, water temperature, conductivity, salinity, dissolved oxygen (both saturation percent and concentration in ppm), chlorophyll, turbidity, pH, and redox potential. This is the water-column counterpart to noaa_marine_get_conditions, which returns surface meteorological and wave data (wind, waves, sea-surface temperature) — use this tool for what the water is doing below the surface, that one for weather and sea state at the buoy. Returns the most recent observation as one reading per reported depth; most stations report a single depth, but some report several at the same time. Sensor coverage is sparse — most stations populate only water temperature and salinity — and any value the station did not report comes back null rather than a fabricated zero. Latitude and longitude are null when the station is absent from the NDBC active-stations list. Sub-surface sensors are on only a subset of NDBC stations and are not marked by any station-catalog flag, so no capability filter guarantees coverage: call this on candidate NDBC station IDs from noaa_marine_find_stations with source="ndbc", and expect the observations_not_found error on the many stations that serve no .ocean file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
station_idYesNDBC station ID (5-character alphanumeric, e.g. "44033" or "TIBC1"). Obtain candidate IDs from noaa_marine_find_stations with source="ndbc" — ocean-sensor coverage is not flagged in the catalog, so this is a best-effort call on any NDBC station.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
sourceNoData source — always "ndbc" for this tool.
latitudeNoStation latitude in decimal degrees. Null when the station is absent from the NDBC active-stations list — the .ocean feed carries observations but no coordinates.
readingsNoPer-depth readings sharing the most recent observation timestamp, in NDBC source order.
longitudeNoStation longitude in decimal degrees. Null when the station is absent from the NDBC active-stations list.
station_idNoStation ID echoed from the request — for chaining.
observed_atNoISO 8601 UTC timestamp of the observation.
station_nameNoStation name from the NDBC active stations list.
reading_countNoNumber of per-depth readings in the latest observation (usually 1).

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, but the description goes further, disclosing that unreported values come back null (not zero), that lat/lon are null when a station is absent from the active list, and that sensor coverage is sparse. It also specifies the error condition. No contradiction with annotations.

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

Conciseness4/5

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

The description is long but each sentence earns its place, covering purpose, distinctions, data behavior, and failure modes. It is front-loaded with the core purpose and follows a logical structure, though slightly dense.

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 presence of an output schema (so return values do not need describing), the description covers data list, null-handling policy, coordinate behavior, station coverage caveats, and error handling. It also connects to sibling tools. Nothing essential is missing for an agent to call this correctly.

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 description coverage is 100% and the schema itself provides a detailed station_id description with pattern and example. The tool description supplements this by explaining that station IDs should be sourced from find_stations and that coverage is not guaranteed, adding practical context beyond the 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 states a specific verb-resource pairing: 'Live sub-surface oceanographic observations from an NDBC station's water-quality sensors.' It enumerates the data types returned and explicitly contrasts with the sibling noaa_marine_get_conditions, leaving no ambiguity about what the tool does.

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?

Gives explicit when-to-use guidance: 'use this tool for what the water is doing below the surface, that one for weather and sea state at the buoy.' Also instructs how to obtain candidate IDs via noaa_marine_find_stations with source="ndbc" and warns that many stations will produce an observations_not_found error. This thoroughly differentiates from alternatives.

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