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
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
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.
Tool Definition Quality
Average 4.6/5 across 6 of 6 tools scored.
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.
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.
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.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), description details return content, station ID formats, platform vs capabilities distinction, and notes about CO-OPS current stations. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded, but somewhat lengthy. Every sentence adds value; no redundancy. Could be slightly more concise but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (none required), 100% schema coverage, output schema, and annotations, the description is fully complete. It covers all aspects a user needs, including edge cases and cross-tool advice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant meaning: explains station ID patterns, how types filter works (capability vs platform), and parameter interactions (state restricts to CO-OPS, lat/lng required together).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds CO-OPS and NDBC stations by location/name/state, and explicitly positions it as the required first step before data tools. It distinguishes from sibling tools that retrieve data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: required first step, how to combine parameters (latitude+longitude, query/state), and even a troubleshooting tip for noaa_marine_get_currents. Tells when to use each filter type.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds valuable details: update frequency (~10 min), potential staleness (10-20 min), normal null values for missing sensors, and unit exceptions (tide in feet, visibility in nautical miles). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is informative but slightly verbose; could tighten some sentences. However, it effectively front-loads the main output and organizes details logically (units, nulls, update rate, usage tips).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown), the description need not detail return values. It covers input semantics, behavioral expectations, and usage guidance comprehensively. No gaps evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter station_id. Description adds meaningful context: pattern, example, and method to obtain correct ID. Exceeds schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves live marine conditions from an NDBC buoy, listing specific parameters (wave height, wind, temperature, pressure, dew point). Distinguishes from sibling tools like noaa_marine_find_stations (discovery) and noaa_marine_get_currents (different data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use (need live buoy data) and provides guidance on finding compatible station IDs via noaa_marine_find_stations with specific filters. Notes that some stations do not report data. Lacks direct comparison to other conditions tools but still informative.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Descriptions adds that depth bins are reported whenever NDBC gives a depth, and direction or speed is null when the sensor did not report that component, going beyond the readOnlyHint and openWorldHint annotations to clarify data completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences front-load the purpose, then detail units and null handling, then usage guidance. No redundancy; every sentence is informative and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 correctly focuses on input and behavioral details (null values, unit definitions, station selection advice). It is fully complete for a read-only data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (station_id) with 100% schema coverage and a descriptive field in the schema. The tool description does not add new parameter-level information beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides 'observed ocean-current depth profile from an NDBC ADCP buoy: the most recent measurement of current speed and direction at each depth bin,' which is a specific verb+resource. It also distinguishes from the sibling tool noaa_marine_get_currents by contrasting observed vs. forecast tidal data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with noaa_marine_get_currents (CO-OPS tidal predictions vs. observed ADCP), advises using noaa_marine_find_stations with specific filters to find usable station IDs, and warns that most NDBC stations serve no ADCP profile.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds key behaviors: data source (CO-OPS), distinction from observed data, default interval practical for planning, optional continuous data, station ID format, and date range limitation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs. First sentence states purpose and return data. Second sentence distinguishes from sibling. Then explains defaults, optional interval, station ID format, date limit, and how to find stations. Every sentence is informative and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, 3 enums, and an output schema, the description covers all relevant aspects: each parameter's purpose, default behavior, limitations (1 year), and relationship to other tools. It is complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds significant meaning: explains MAX_SLACK vs 6min, units (knots vs m/s), time zone options, station ID pattern and how to obtain, and the practical use of defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides tidal current predictions (max flood/ebb speeds, slack times, directions) for a CO-OPS station, and explicitly distinguishes it from the sibling noaa_marine_get_current_profile, which returns observed ocean currents 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: use for CO-OPS forecast tidal currents, alternative for observed profiles, explains default interval (MAX_SLACK) and when to use 6min, notes date range limit of 1 year, and directs to noaa_marine_find_stations for obtaining station IDs.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint) are complemented by detailed behavioral notes: returns one reading per depth, null for unreported values, null lat/lon for inactive stations, and no capability filter for sensor coverage. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough and well-structured but slightly verbose. However, every sentence adds necessary context, so it earns a high score despite not being the most concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations are rich, the description covers all essential aspects: data returned, null handling, station coverage limitations, error conditions, and relationship to sibling tools. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, providing format, pattern, and source instructions. The description reinforces this but adds no new semantic details beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Live sub-surface oceanographic observations' and lists exact parameters (temperature, salinity, etc.). It directly contrasts with sibling noaa_marine_get_conditions by stating 'water-column counterpart' vs surface data, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'use this tool for what the water is doing below the surface, that one for weather and sea state.' Also advises to obtain station IDs from noaa_marine_find_stations with source='ndbc' and warns about expected errors, providing clear decision context.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context like the 1-year date range limit, datum default (MLLW), interval options, and time zone options. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded first sentence states core functionality. Every sentence adds value: purpose, interval distinction, datum note, date limit, prerequisite. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 and strong annotations, the description covers purpose, usage, constraints, and integrates with sibling tools. Could mention pagination or response format, but output schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema (e.g., 'MLLW is standard for US nautical charts'), which is helpful but not significantly beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns high/low tide predictions for a CO-OPS station over a date range, specifying time, height, and tide type. It distinguishes between hilo and 6min intervals and mentions datum defaults. It differentiates from sibling tools by instructing to use noaa_marine_find_stations first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use noaa_marine_find_stations to resolve a station name/location to a numeric ID. Notes the 1-year date range limit and advises splitting longer ranges across multiple calls, providing clear when-to-use and when-not-to-use guidance.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds useful behavioral details: returns 6-minute data, computes residual, and mentions date range limit. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences plus actionable guidance. It front-loads the core purpose and uses efficient language without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, the description adequately covers all essential aspects: data resolution, residual meaning, date range limits, and prerequisite station lookup. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 context for station_id (how to obtain) and datum (explaining common datums), but most parameters already have clear schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 levels with paired predictions, including the residual calculation. It specifies 6-minute observations and distinguishes itself from sibling tools by referencing noaa_marine_find_stations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use noaa_marine_find_stations first to obtain a valid station ID, and advises splitting date ranges longer than 31 days into multiple calls. While it does not explicitly state when not to use, the context is clear.
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!