Skip to main content
Glama

noaa-marine-mcp-server

by io.github.cyanheads

Get Tidal Currents

noaa_marine_get_currents
Read-onlyIdempotent

Tidal current predictions for a CO-OPS current station: max flood/ebb speeds, slack times, and directions. These are forecast tidal-current predictions from CO-OPS — distinct from noaa_marine_get_current_profile, which returns NDBC observed ocean-current measurements binned by depth. Defaults to MAX_SLACK interval — the practical planning view showing when currents peak and when slack water occurs. Optionally returns 6-minute continuous predictions for detailed analysis. Current station IDs use alphanumeric format (e.g. ACT4176), distinct from numeric tide/water-level IDs. Date range is limited to 1 year per request. Use noaa_marine_find_stations with types=["current"] to obtain valid current station IDs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
unitsNoUnit system: english = knots; metric = m/s.english
end_dateYesEnd date in YYYYMMDD format (inclusive), e.g. "20240607".
intervalNoPrediction interval: MAX_SLACK (default) returns max flood, max ebb, and slack water events — ideal for passage planning. 6min returns a continuous current curve.MAX_SLACK
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 current station ID (alphanumeric, e.g. "ACT4176"). Obtain from noaa_marine_find_stations with types=["current"].

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
unitsNoSpeed units: "english" (knots) or "metric" (m/s).
eventsNoMax flood, max ebb, and slack events. Present for MAX_SLACK interval.
station_idNoStation ID echoed from the request — for chaining.
predictionsNo6-minute continuous current predictions. Present for 6min interval.
station_nameNoStation name as returned by CO-OPS.

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already establish readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context beyond that: it specifies the data source (CO-OPS forecast predictions, not observations), the 1-year date range limit, and warns that current station IDs are alphanumeric and distinct from numeric tide/water-level IDs. 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.

Conciseness5/5

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

The description is dense but every sentence contributes value: core capability, sibling distinction, default interval rationale, optional detail mode, station ID caveat, and date limit. It is front-loaded with the primary purpose and flows logically, with no fluff or redundancy.

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 (which covers return values) and the rich annotations, the description covers all essential context: data source (CO-OPS forecast vs observations), how to obtain valid inputs (find_stations), key constraints (1-year limit, station ID format), and the distinction from sibling tools. An agent has everything needed to decide when and how to invoke this tool.

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 documentation covers all 6 parameters with descriptions, enums, defaults, and patterns (100% coverage), so the baseline is 3. The description supplements this by clarifying the station_id format (alphanumeric, distinct from numeric IDs) and noting the 1-year date range constraint, which helps agents understand the scope of begin_date/end_date beyond what the schema states.

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 it provides tidal current predictions for a CO-OPS station, listing the specific outputs (max flood/ebb speeds, slack times, directions). It also explicitly names the sibling noaa_marine_get_current_profile and contrasts it (NDBC observed ocean-current measurements, depth-binned), so an agent can immediately distinguish the two without inspecting their schemas.

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 directs users to noaa_marine_find_stations for obtaining valid station IDs and highlights the difference from noaa_marine_get_current_profile for observed data. It also explains when to use the default MAX_SLACK interval (planning view) versus the optional 6-minute continuous predictions (detailed analysis), providing clear context for choosing this tool over 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