Skip to main content
Glama

noaa-marine-mcp-server

by io.github.cyanheads

Find Marine Stations

noaa_marine_find_stations
Read-only

Find CO-OPS tide/water-level/current stations and NDBC buoys near a location or by name/state. Returns a unified station list with source, data capabilities, coordinates, and — for NDBC — the physical platform class. This is the required first step to resolve place names or coordinates to station IDs before calling data tools. CO-OPS station IDs are numeric (e.g. 9447130 for Seattle); current station IDs are alphanumeric (e.g. ACT4176). NDBC buoy IDs are 5-character alphanumeric codes (e.g. 46041). Two axes are reported separately: capabilities/type describe the data products a station serves (tide, current, water_level, met, current_profile), while platform is the NDBC physical classification (buoy, fixed, oilrig, dart, tao, usv, other). CO-OPS stations carry no platform class. Provide latitude and longitude together for proximity search, or query/state for name-based search — both may be combined. Note: CO-OPS current stations are cataloged by monitoring capability, not prediction availability. If noaa_marine_get_currents returns no_predictions for a station, try the next nearest current station.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of stations to return. Defaults to 20.
queryNoStation name substring to match, case-insensitive. E.g. "seattle", "puget sound". NDBC rows also match on station ID. Blank or whitespace-only values are treated as omitted.
stateNoFilter by 2-letter US state or territory code. Applies to CO-OPS stations only — providing it restricts results to CO-OPS and excludes NDBC buoys (which carry no state). E.g. "WA", "CA", "PR".
typesNoFilter by data capability or NDBC platform class. Every returned station matches at least one requested value — a capability value against its capabilities list, or buoy against its platform class. Omit to return all stations.
sourceNoData source to search: coops (tide/water-level/current stations), ndbc (buoys), or all (default).all
latitudeNoCenter latitude in decimal degrees for proximity search. Required together with longitude — supplying only one is rejected rather than silently ignored. Optionally pair with radius_km.
longitudeNoCenter longitude in decimal degrees for proximity search. Required together with latitude — supplying only one is rejected rather than silently ignored. Optionally pair with radius_km.
radius_kmNoSearch radius in kilometers when latitude/longitude are provided. Defaults to 100 km.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
stationsNoStations matching the search criteria, sorted by distance (if lat/lon provided) or name.
truncatedNoTrue when total_found exceeds the limit and not all matching stations are returned. Increase limit or narrow filters to see more.
total_foundNoTotal stations matching the filters before the limit was applied.

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it explains the distinction between data capabilities and physical platform (the two axes), notes that CO-OPS current stations are cataloged by monitoring capability, and warns about no_predictions from noaa_marine_get_currents. This is substantive, though it does not disclose rate limits or pagination details, which are minor for a read-only search tool.

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 slightly long (about 200 words) but each sentence contributes unique information—ID formats, axes, search requirements, and the no_predictions note. It is front-loaded with the primary purpose and then provides necessary technical specifics. No redundant statements; it earns a 4 for being structured and efficient despite its length.

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 has 8 parameters, an output schema, and multiple search modes, the description is remarkably complete. It covers the two filtering axes, the source-specific behavior, the ID formats, and the prerequisite nature for other data tools. Since an output schema exists, it doesn't need to detail return values, and it doesn't. Nothing critical is missing for correct invocation.

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 baseline is 3. The description adds meaning beyond the schema: it clarifies that 'state' applies only to CO-OPS stations (excluding NDBC), that the 'buoy' type filters by physical platform rather than data capability, and that latitude/longitude must be provided together. This helps the agent avoid common parameter misuse, earning a 4.

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 ('Find') with a clear resource ('CO-OPS tide/water-level/current stations and NDBC buoys') and distinguishes it from sibling data tools by noting it is the 'required first step to resolve place names or coordinates to station IDs before calling data tools.' It also clarifies the unified station list content, making the tool's role unambiguous.

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 states when to use this tool: 'This is the required first step... before calling data tools.' It also gives practical guidance on search modes ('Provide latitude and longitude together for proximity search, or query/state for name-based search'), and mentions the fallback behavior when no_predictions are encountered. This goes beyond implicit usage and clearly routes the agent.

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