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
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.5/5 across 5 of 5 tools scored.
Each tool targets a distinct marine data type: station search, buoy conditions, tidal currents, tide predictions, and water levels. There is no overlap or ambiguity between them.
All tools follow the consistent pattern 'noaa_marine_<verb>_<noun>', using lowercase with underscores. The verbs are descriptive (find, get, get, get, get) and the nouns clearly indicate the data type.
Five tools is an appropriate number for a marine data API. Each tool covers a core function (station lookup, conditions, currents, tides, water levels) without unnecessary redundancy.
The set covers the primary marine data types: stations, live buoy conditions, currents, tide predictions, and water levels. Minor gaps exist (e.g., no wave forecast or wind predictions), but the core observational and prediction needs are addressed.
Available Tools
5 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, type, capabilities, and coordinates. 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). Provide latitude/longitude 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 search (case-insensitive token match). E.g. "seattle", "puget sound". | |
| 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 station type/capability. Omit to return all types. | |
| 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. Pair with longitude and optionally radius_km. | |
| longitude | No | Center longitude in decimal degrees for proximity search. Pair with latitude and optionally 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), the description adds station ID formats, the fact that state restricts to CO-OPS, and the no_predictions note. 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?
The description is slightly long but each sentence adds value. Front-loaded with core purpose, though could be trimmed slightly.
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, 0 required, and output schema exists, the description is thorough: covers usage, station IDs, and troubleshooting for no_predictions.
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 the description adds value by explaining combinations (lat/long with radius, query/state) and the state restriction to CO-OPS only.
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 near a location or by name/state, and returns a unified station list. It distinguishes from sibling data retrieval tools by noting this is the required first step.
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 says it's the required first step before calling data tools, gives guidance on station ID formats, and provides context on combining parameters and handling no_predictions for current stations.
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" to find buoy station IDs near a location.
| 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". |
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 set readOnlyHint=true and openWorldHint=true. Description adds valuable context: update frequency (~10 min), possible data lag (10–20 min), null values for unreported sensors, and unit exceptions (TIDE in feet, VIS in nautical miles). 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?
Single paragraph front-loaded with main purpose, followed by essential details (units, null handling, update frequency, sibling tool reference). Every sentence earns its place without redundancy.
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 an output schema present, description fully covers: data source, fields, units, exceptional units, null behavior, update frequency, and station ID acquisition. Comprehensive for a single-parameter 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?
Schema coverage is 100% with a detailed description for station_id including pattern and example. Description adds some value (linking to find_stations) but doesn't significantly expand beyond what the schema already provides. 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?
Clearly states it provides live marine conditions from an NDBC buoy and lists specific parameters (wave height, wind, etc.). Distinguishes from sibling tool noaa_marine_find_stations by mentioning it for finding station IDs.
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 to use noaa_marine_find_stations with source='ndbc' to find station IDs. Implicitly defines when to use this tool (when live buoy data is needed), though no explicit 'when not to use' is given.
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. 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?
The description adds behavioral details beyond the annotations: it specifies the default interval behavior, the format of IDs, and the date range limit. Annotations already state readOnlyHint, openWorldHint, and idempotentHint as true, and the description aligns without contradiction, providing additional context about data and limitations.
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 five sentences, front-loaded with the main purpose, and includes only necessary details without redundancy. It is well-structured and concise, earning its place with every sentence providing value.
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?
The description is comprehensive given the tool's complexity: it covers purpose, parameter usage, defaults, limitations (date range, ID format), and references a sibling tool for station lookup. The output schema exists, so return values are not needed in the description. No gaps are apparent.
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% with all parameters described. The description adds extra meaning for key parameters: it explains the practical use of the interval parameter and clarifies that station IDs are alphanumeric and distinct from tide IDs. This adds value beyond the schema, justifying a score above the baseline of 3.
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 retrieves tidal current predictions for a CO-OPS station and specifies the return data (max flood/ebb speeds, slack times, directions). It distinguishes from sibling tools by mentioning the alphanumeric station ID format and referencing noaa_marine_find_stations, providing a specific verb and resource.
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 explains the default interval (MAX_SLACK) for practical planning versus 6min for detailed analysis, and notes the date range limit of 1 year. It gives guidance on obtaining valid station IDs via noaa_marine_find_stations. However, it does not explicitly compare with sibling tools like get_tide_predictions or get_water_level, so while clear context is provided, direct alternatives are not mentioned.
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!