A
license-
qualityF
maintenanceProvides NOAA tide predictions and observed water levels, allowing AI agents to query tide stations and current water level data.
3
MIT
noaa-marine-mcp-server
Server Details
Find NOAA tide stations and NDBC buoys, fetch tide predictions, currents, and live conditions.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/noaa-marine-mcp-server
- GitHub Stars
- 1
- Server Listing
- @cyanheads/noaa-marine-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.5/5.0
Tool DescriptionsA
Average 4.6/5 across 6 of 6 tools scored.
Server CoherenceA
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.
Available Tools
7 toolsnoaa_marine_find_stationsFind Marine StationsARead-onlyInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of stations to return. Defaults to 20. | |
| query | No | Station 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. | |
| state | No | Filter 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". | |
| types | No | Filter 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. | |
| source | No | Data source to search: coops (tide/water-level/current stations), ndbc (buoys), or all (default). | all |
| latitude | No | Center 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. | |
| longitude | No | Center 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_km | No | Search radius in kilometers when latitude/longitude are provided. Defaults to 100 km. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| stations | Yes | Stations matching the search criteria, sorted by distance (if lat/lon provided) or name. |
| truncated | No | True when total_found exceeds the limit and not all matching stations are returned. Increase limit or narrow filters to see more. |
| total_found | Yes | Total stations matching the filters before the limit was applied. |
Tool Definition Quality
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and openWorldHint, so description adds value by detailing output structure (source, capabilities, coordinates, platform), ID formats, and the rejection of partial lat/lon. This goes beyond what annotations provide.
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 front-loaded with purpose and structured logically. It is slightly long but every sentence adds necessary context for a complex tool with multiple parameter groups and sources. Could be tightened slightly.
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 output schema exists, the description does not need to explain return values. It covers the essential information for a first-step discovery tool: ID formats, parameter usage, and a note about CO-OPS current stations. It is thorough and relevant.
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 covers 100% of parameters, so baseline is 3. Description enhances understanding by explaining how to combine lat/lon and query/state, and that partial lat/lon is rejected. It also clarifies the meaning of capabilities vs platform.
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 the tool's purpose: find CO-OPS and NDBC stations by location or name. It distinguishes itself from sibling data tools by explicitly marking itself as the required first step before calling data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool (first step), how to use parameters together (lat/lon, query/state), and hints for handling no_predictions. However, it does not explicitly state when not to use this tool or list alternatives to other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_marine_get_conditionsGet Marine ConditionsARead-onlyInspect
Live marine conditions from an NDBC buoy: wave height/period/direction, wind speed/gust/direction, sea-surface temperature, air temperature, barometric pressure, and dew point. All values are SI units — wind in m/s, wave height in m, pressure in hPa, temperatures in °C. Exceptions: TIDE is in feet and VIS is in nautical miles (rarely populated at offshore buoys). Numeric fields are null when the buoy sensor did not report a value — this is normal for offshore buoys. Observations are updated approximately every 10 minutes; data may be 10–20 minutes old. Use noaa_marine_find_stations with source="ndbc" and types=["met"] to find station IDs near a location — met-flagged stations are the ones most likely to serve live conditions. Roughly a third of active NDBC stations report neither meteorological nor current data, and most of those have no observation file, so omitting the types filter will surface station IDs this tool cannot read.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| station_id | Yes | NDBC buoy station ID (5-character alphanumeric, e.g. "46041" for Cape Elizabeth). Obtain from noaa_marine_find_stations with source="ndbc" and types=["met"]. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| source | Yes | Data source — always "ndbc" for this tool. |
| tide_ft | Yes | Tide height in feet. NOTE: always in feet regardless of other unit settings. Rarely populated at offshore buoys. Null if not reported. |
| latitude | Yes | Station latitude in decimal degrees. |
| longitude | Yes | Station longitude in decimal degrees. |
| air_temp_c | Yes | Air temperature in °C. Null if not reported. |
| station_id | Yes | Station ID echoed from the request — for chaining. |
| dew_point_c | Yes | Dew point temperature in °C. Null if not reported. |
| observed_at | Yes | ISO 8601 UTC timestamp of the observation row used. |
| pressure_hpa | Yes | Atmospheric pressure in hPa. Null if not reported. |
| station_name | Yes | Station name from the NDBC active stations list. |
| water_temp_c | Yes | Sea-surface temperature in °C. Null if not reported. |
| gust_speed_ms | Yes | Wind gust speed in m/s. Null if not reported. |
| wave_height_m | Yes | Significant wave height in meters. Null if not reported. |
| wind_speed_ms | Yes | Wind speed in m/s. Null if not reported. |
| visibility_nmi | Yes | Visibility in nautical miles. NOTE: always in nautical miles regardless of other unit settings. Null if not reported. |
| average_period_sec | Yes | Average wave period in seconds. Null if not reported. |
| wind_direction_deg | Yes | Wind direction in degrees true (0–360). Null if not reported by the buoy. |
| dominant_period_sec | Yes | Dominant wave period in seconds. Null if not reported. |
| mean_wave_direction_deg | Yes | Mean wave direction in degrees true. Null if not reported. |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses update frequency (~10 min), potential data latency (10–20 min old), null handling for missing sensor data, and non-SI units for TIDE and VIS. No contradictions 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 detailed but each sentence serves a purpose: data fields, units, null behavior, update frequency, and guidance on station selection. It could be slightly trimmed but remains efficient and front-loaded with the most important information.
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 a single parameter and an output schema (not shown), the description covers all necessary context: returned data, units, nulls, update cadence, data freshness, and how to find valid station IDs. No gaps identified.
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?
The input schema already describes the station_id parameter with format and example. The description adds value by explaining how to obtain a valid station_id via a sibling tool and mentioning the 5-character alphanumeric pattern, but the baseline schema coverage is 100%, limiting additional contribution.
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 explicitly states it returns 'live marine conditions from an NDBC buoy' and lists the specific data fields (wave height/period/direction, wind, SST, etc.). This clearly identifies the tool's function and distinguishes it from sibling tools like noaa_marine_get_currents or noaa_marine_get_ocean_observations.
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 provides explicit guidance on when to use this tool: 'Use noaa_marine_find_stations with source="ndbc" and types=["met"] to find station IDs' and warns that 'omitting the types filter will surface station IDs this tool cannot read.' This includes when-not-to-use and alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_marine_get_current_profileGet Ocean Current ProfileARead-onlyInspect
Observed ocean-current depth profile from an NDBC ADCP buoy: the most recent measurement of current speed and direction at each depth bin. Returns depth in meters, direction in degrees true (the direction the current flows toward), and speed in cm/s. Distinct from noaa_marine_get_currents, which returns CO-OPS tidal-current predictions (forecast max flood/ebb/slack) rather than these observed acoustic-Doppler measurements. A depth bin is reported whenever NDBC gives it a depth; its direction or speed is null when the sensor did not report that component. Use noaa_marine_find_stations with source="ndbc" and types=["current_profile"] to find station IDs — most NDBC stations serve no ADCP profile, so an unfiltered search returns IDs this tool cannot read.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| station_id | Yes | NDBC station ID (5-character alphanumeric, e.g. "44033"). Obtain from noaa_marine_find_stations with source="ndbc" and types=["current_profile"]. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| bins | Yes | Depth-binned current measurements, shallowest first (NDBC source order). |
| source | Yes | Data source — always "ndbc" for this tool. |
| latitude | Yes | Station latitude in decimal degrees. Null when the station is absent from the NDBC active-stations list — the ADCP feed carries current data but no coordinates. |
| bin_count | Yes | Number of depth bins in the profile. |
| longitude | Yes | Station longitude in decimal degrees. Null when the station is absent from the NDBC active-stations list. |
| station_id | Yes | Station ID echoed from the request — for chaining. |
| observed_at | Yes | ISO 8601 UTC timestamp of the observation. |
| station_name | Yes | Station name from the NDBC active stations list. |
Tool Definition Quality
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds behavioral details: depth bins reported only when given a depth, and direction or speed can be null if not reported. 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 a single coherent paragraph, front-loading the primary output, then adding units, distinction, and usage notes. Every sentence is meaningful and concise.
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?
Despite simplicity (one parameter, output schema exists), the description covers what is returned, units, null handling, and how to find valid station IDs, making it complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, already specifying station_id format and how to obtain it. The description reinforces using noaa_marine_find_stations but adds no new parameter semantics 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 clearly states the tool returns observed ocean-current depth profiles from NDBC ADCP buoys, listing specific measurements (depth, direction, speed) and distinguishes from the sibling tool noaa_marine_get_currents which returns tidal predictions.
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?
Explicitly differentiates from noaa_marine_get_currents, advises using noaa_marine_find_stations to obtain station IDs, and warns that unfiltered searches may yield IDs not usable by this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_marine_get_currentsGet Tidal CurrentsARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| units | No | Unit system: english = knots; metric = m/s. | english |
| end_date | Yes | End date in YYYYMMDD format (inclusive), e.g. "20240607". | |
| interval | No | Prediction 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_zone | No | Time zone for returned timestamps. lst_ldt = local standard/daylight time (default); gmt = UTC; lst = local standard time year-round. | lst_ldt |
| begin_date | Yes | Start date in YYYYMMDD format, e.g. "20240601". | |
| station_id | Yes | CO-OPS current station ID (alphanumeric, e.g. "ACT4176"). Obtain from noaa_marine_find_stations with types=["current"]. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| units | Yes | Speed units: "english" (knots) or "metric" (m/s). |
| events | No | Max flood, max ebb, and slack events. Present for MAX_SLACK interval. |
| station_id | Yes | Station ID echoed from the request — for chaining. |
| predictions | No | 6-minute continuous current predictions. Present for 6min interval. |
| station_name | Yes | Station name as returned by CO-OPS. |
Tool Definition Quality
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and open-world. The description adds valuable context: predictions are forecast tidal-current from CO-OPS, default interval returns max/ebb/slack events, optional 6min returns continuous curve, station IDs are alphanumeric, and date range is limited to 1 year.
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 efficient (4-5 sentences) and front-loaded: starts with core purpose, then differentiates from sibling, explains defaults, optional behavior, and ancillary information like station ID format and source. Every sentence provides necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, annotations, output schema exists), the description covers purpose, behavior (intervals, units, time zones), constraints (1-year date range), and how to find station IDs. It differentiates from a key sibling tool. Some users might want explicit mention of error handling or rate limits, but overall it's very complete.
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 covers all 6 parameters with descriptions (100% coverage), so baseline is 3. The description adds meaning beyond schema by explaining default interval behavior, the practical difference between intervals, and how to obtain station IDs. It reinforces and contextualizes the schema definitions.
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 the tool returns tidal current predictions (max flood/ebb speeds, slack times, directions) for a CO-OPS station. It distinguishes from sibling noaa_marine_get_current_profile by specifying that tool returns NDBC observed ocean-current measurements binned by depth.
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?
Provides explicit guidance on when to use each interval: MAX_SLACK for practical planning (peak currents and slack water) and 6min for detailed continuous analysis. Directs users to noaa_marine_find_stations to obtain valid station IDs. Also notes a 1-year date range limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_marine_get_ocean_observationsGet Ocean ObservationsARead-onlyInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| station_id | Yes | NDBC 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| source | Yes | Data source — always "ndbc" for this tool. |
| latitude | Yes | Station latitude in decimal degrees. Null when the station is absent from the NDBC active-stations list — the .ocean feed carries observations but no coordinates. |
| readings | Yes | Per-depth readings sharing the most recent observation timestamp, in NDBC source order. |
| longitude | Yes | Station longitude in decimal degrees. Null when the station is absent from the NDBC active-stations list. |
| station_id | Yes | Station ID echoed from the request — for chaining. |
| observed_at | Yes | ISO 8601 UTC timestamp of the observation. |
| station_name | Yes | Station name from the NDBC active stations list. |
| reading_count | Yes | Number of per-depth readings in the latest observation (usually 1). |
Tool Definition Quality
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 description adds critical details: sparse sensor coverage, nulls for unreported values, potential null lat/lng, and absence of catalog flags for sub-surface sensors. No contradictions 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 detailed but each sentence adds essential information. It is front-loaded with the core purpose. Minor wordiness could be trimmed, but it remains clear and efficient.
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 single parameter and existence of output schema, the description fully covers expected behavior, data quality, error scenarios, and integration with sibling tools. No gaps remain.
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% (single parameter with pattern and description). The description adds value by explaining the parameter's purpose, providing an example, and linking to noaa_marine_find_stations for candidate IDs. This exceeds the baseline of 3.
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?
Clearly states it returns live sub-surface oceanographic observations from NDBC stations. Distinguishes from sibling noaa_marine_get_conditions by specifying that tool returns surface meteorological and wave data.
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?
Explicitly advises using this tool for water-column data and noaa_marine_get_conditions for surface weather/sea state. Also instructs to call on candidate station IDs from noaa_marine_find_stations and warns that many stations will return an error.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_marine_get_tide_predictionsGet Tide PredictionsARead-onlyIdempotentInspect
High/low tide predictions for a CO-OPS tide station over a date range. Returns time, height, and tide type (H=high, L=low) for each event when using the default hilo interval, or 6-minute interval predictions for a detailed tide curve. Datum defaults to MLLW (mean lower low water — standard for US nautical charts). Date range is limited to 1 year per request; split longer ranges across multiple calls. Use noaa_marine_find_stations first to resolve a station name or location to a numeric station ID.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| datum | No | Tidal datum reference plane. MLLW (default) is the US nautical chart datum. MSL = mean sea level; MHHW = mean higher high water (flooding reference). | MLLW |
| units | No | Unit system for heights: english = feet; metric = meters. | english |
| end_date | Yes | End date in YYYYMMDD format (inclusive), e.g. "20240607". | |
| interval | No | Prediction interval: hilo (default) returns only high and low tide events; 6min returns a continuous prediction curve at 6-minute intervals. | hilo |
| time_zone | No | Time zone for returned timestamps. lst_ldt = local standard/daylight time (default); gmt = UTC; lst = local standard time year-round. | lst_ldt |
| begin_date | Yes | Start date in YYYYMMDD format, e.g. "20240601". | |
| station_id | Yes | CO-OPS tide station ID (numeric, e.g. "9447130" for Seattle). Obtain from noaa_marine_find_stations with types=["tide"]. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| datum | Yes | Tidal datum used (e.g. MLLW) — echoed for correct interpretation of heights. |
| units | Yes | Height units: "english" (feet) or "metric" (meters). |
| station_id | Yes | Station ID echoed from the request — for chaining. |
| predictions | Yes | Tide predictions for the requested date range. |
| station_name | Yes | Station name as returned by CO-OPS — confirms the correct station was queried. |
Tool Definition Quality
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and open-world. The description adds behavioral context beyond annotations: it clarifies the date range limit (1 year), states the default datum (MLLW), and explains the interval parameter behavior (hilo vs 6min). There is no contradiction with annotations, and the description enriches the agent's understanding of constraints and output behavior.
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 concise with four well-structured sentences. The first sentence states the core purpose. Subsequent sentences add essential details (interval types, datum default, date limit, prerequisite tool). No unnecessary information is included, and critical guidance is front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/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 parameters, 3 required, output schema present), the description covers key aspects: output format, interval options, datum, date restrictions, and station ID sourcing. The presence of an output schema reduces the need to describe return values. Minor gaps include lack of error handling or status codes, but these are beyond typical description scope. Overall, the description is sufficient for an agent to invoke the tool 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?
With 100% schema description coverage, the baseline is 3. The description adds value by providing context for key parameters: it explains the default interval ('hilo'), the default datum ('MLLW' with nautical chart relevance), and the 1-year date range limit. It also recommends using noaa_marine_find_stations for the station_id, which is not in the schema. This additional semantics justifies a score of 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 clearly states it provides 'high/low tide predictions for a CO-OPS tide station over a date range' and specifies the output format (time, height, tide type for hilo, or 6-minute interval predictions). It distinguishes from siblings by referencing noaa_marine_find_stations, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for tide predictions) and provides important usage constraints: the date range is limited to 1 year per request, requiring splitting for longer ranges. It also instructs to first use noaa_marine_find_stations to obtain a station ID. However, it does not explicitly mention when not to use this tool versus alternatives like noaa_marine_get_water_level, though the sibling list implies a broader ecosystem.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_marine_get_water_levelGet Water LevelARead-onlyIdempotentInspect
Observed water level (real-time or historical) for a CO-OPS water-level station, with paired predictions for comparison. The difference (residual = observed − predicted) indicates storm surge (positive) or anomalous drawdown (negative). Returns 6-minute observations alongside 6-minute predictions. Date range is limited to 31 days per request; split longer ranges into multiple calls. Use noaa_marine_find_stations first to resolve a station name or location to a valid station ID.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| datum | No | Tidal datum reference plane. MLLW (default) is the US nautical chart datum. MSL = mean sea level; MHHW = mean higher high water (flooding reference). | MLLW |
| units | No | Unit system: english = feet; metric = meters. | english |
| end_date | Yes | End date in YYYYMMDD format (inclusive), e.g. "20240601". | |
| time_zone | No | Time zone for returned timestamps. lst_ldt = local standard/daylight time (default); gmt = UTC; lst = local standard time year-round. | lst_ldt |
| begin_date | Yes | Start date in YYYYMMDD format, e.g. "20240601". | |
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| datum | Yes | Tidal datum used — echoed for correct interpretation of water heights. |
| units | Yes | Height units: "english" (feet) or "metric" (meters). |
| station_id | Yes | Station ID echoed from the request — for chaining. |
| predictions | Yes | Paired 6-minute tide predictions for the same period. May be empty if CO-OPS predictions are unavailable for this station. |
| observations | Yes | 6-minute observed water level readings. |
| station_name | Yes | Station name as returned by CO-OPS. |
| residual_summary | No | Summary of observed-minus-predicted residuals in the requested units. Only present when both observations and predictions are available. |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds value by specifying that data includes 6-minute observations and predictions, and explains the residual calculation for storm surge detection. No contradictions 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?
Description is extremely concise: 5 sentences, front-loaded with core purpose, then key constraints (31-day limit, residual, find_stations). No wasted words or redundant information.
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 complexity (6 parameters, output schema exists, 100% schema coverage), the description covers all essential aspects: data frequency, residual interpretation, date range limitation, and prerequisite tool usage. It is fully adequate for an agent to use 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 coverage is 100% with inline parameter descriptions. The description adds extra value by detailing the residual formula and hinting at station ID resolution, but does not deeply explain each parameter beyond the schema. Baseline is 3, but the added context merits 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 clearly states the tool returns observed water level with predictions and residual for storm surge indication. It specifies the source (CO-OPS stations) and distinguishes from siblings by directing users to first use noaa_marine_find_stations to resolve station IDs.
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 the tool (to get water level data), imposes a 31-day date range limit with guidance to split longer requests, and advises to use noaa_marine_find_stations first. This provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- Flicense-qualityDmaintenanceProvides Canadian tide predictions from the IWLS API, enabling retrieval of 7-day tide forecasts and station listings for monitoring stations across Canada.
- Alicense-qualityBmaintenanceProvides real-time water temperature and tide predictions for any lake, river, ocean, bay, or beach using NOAA, USGS, and other sources.MIT
- Alicense-qualityAmaintenanceGet US weather forecasts, active alerts, and current observations via the National Weather Service API.2811Apache 2.0
Try in Browser
Your Connectors
Sign in to create a connector for this server.