Skip to main content
Glama

NOAA Tides and Currents

by io.github.RyanCardin15
OverviewAdmin

Get High Tide Flooding Data

noaa_get_high_tide_flooding
Read-onlyIdempotent

Get NOAA high tide flooding (HTF, "nuisance"/"sunny day" flooding) statistics for a station. Reports:

  • daily: flood occurrence per day (REQUIRES start_date and end_date, YYYYMMDD)

  • monthly / seasonal / annual: counts of minor/moderate/major flood days per period (filter with year/month/season_months, or range = last N periods)

  • met_year_annual: counts by meteorological year (May–April)

  • annual_outlook: NOAA's projected flood-day outlook for the coming met year

  • projections: decadal flood-day projections through 2100 (filter by decade, flood_threshold)

  • record_days: record flood-day counts

  • likely_scenarios: likely decadal flooding scenarios

  • daily_likelihoods: day-by-day flood likelihood forecasts

Use for: "how often does X flood?", trends in nuisance flooding, future flooding projections. Not all stations have HTF products — check the HTFhistorical flag via noaa_get_station_info.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearNoFilter to a calendar year (monthly/seasonal/annual/record_days).
monthNoFilter to a month (monthly report).
rangeNoNumber of years to cover: with year (or met_year) set, returns year..year+range; without, returns the last N years.
decadeNoDecade for projections/likely_scenarios (e.g. 2050).
reportNoWhich HTF report to retrieve (see tool description).annual
stationYesStation ID. Water-level/met stations use 7-digit numeric IDs (e.g. "9414290" San Francisco); current stations use alphanumeric IDs (e.g. "cb0102"). Find stations with noaa_search_stations or noaa_find_nearest_stations.
end_dateNoYYYYMMDD — required for report "daily".
met_yearNoMeteorological year (met_year_annual / annual_outlook).
start_dateNoYYYYMMDD — required for report "daily".
season_monthsNoSeason for the seasonal report (Dec-Jan-Feb, Mar-Apr-May, ...).
flood_thresholdNoFlood severity threshold for projections/likely_scenarios.
response_formatNoOutput format: "markdown" for a readable summary table, "json" for the complete structured payload.markdown

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context, such as parameter dependencies (e.g., 'daily REQUIRES start_date and end_date') and the ability to choose output format via the response_format parameter. 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 well-structured with a clear one-line summary followed by a bulleted list of report types. It front-loads key information and each line serves a purpose. While lengthy, the structured format aids readability and the content is necessary for such a parameter-rich tool.

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 has 12 parameters and no output schema, the description is fairly complete. It covers all report types, parameter requirements, and mentions a prerequisite check. It could further detail return behavior or edge cases, but overall it provides sufficient context 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?

Schema description coverage is 100%, but the description goes beyond by explaining each report type's purpose and required parameters (e.g., start_date/end_date for daily). It also clarifies that year, month, range, and other filters apply to specific reports, adding meaning beyond the bare schema descriptions.

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 identifies the tool as retrieving NOAA high tide flooding statistics for a station. It explicitly lists the many report types (daily, monthly, seasonal, etc.) with brief explanations, distinguishing it from sibling tools like noaa_get_tide_predictions or noaa_get_water_levels.

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 states 'Use for: "how often does X flood?", trends in nuisance flooding, future flooding projections' and includes a critical caveat: 'Not all stations have HTF products — check the HTFhistorical flag via noaa_get_station_info.' This provides clear context and a prerequisite check, though it does not explicitly list when not to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All NOAA Tides and Currents toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources