noaa-tidesandcurrents-mcp

Get Station Info

noaa_get_station_info

Read-onlyIdempotent

Retrieve a NOAA station's full metadata—location, time zone, tide type, capability flags, and sub-resource links—to confirm what data it collects before requesting observations.

Instructions

Get a NOAA station's full metadata record: location, state, time zone, tide type, Great Lakes flag, capability flags, and links to available sub-resources.

Optionally expand sub-resources inline via the "expand" list:

details (established/removed dates), sensors (installed instruments + elevations), floodlevels (NOS/NWS minor/moderate/major flood thresholds), benchmarks, products (available data page links), notices, disclaimers — for water-level stations
bins (ADCP depth bins), deployments — for current stations (alphanumeric IDs)

Use this before requesting data to confirm what the station actually collects. For datum values use noaa_get_station_datums; for harmonic constituents use noaa_get_harmonic_constituents.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`units`	No	Unit system. english: feet, °F, knots (wind AND currents), nautical miles. metric: meters, °C, m/s for wind but cm/s for currents, kilometers. Air pressure is millibars and salinity is PSU in BOTH systems.	english
`expand`	No	Sub-resources to embed inline (availability varies by station type).
`station`	Yes	Station 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.
`response_format`	No	Output format: "markdown" for a readable summary table, "json" for the complete structured payload.	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`_response`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.1Oct 5, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds behavior beyond that: it explains that expand availability varies by station type and distinguishes water-level sub-resources from current-station sub-resources (bins, deployments), which helps set expectations.

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 front-loaded with the tool's purpose, then uses a compact bullet list to unpack the expand options, and closes with usage routing. Despite its length, every section earns its place for a tool with nine expandable sub-resources.

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 that output_schema exists and annotations cover safety, the description only needs to cover purpose, usage, and parameter meaning. It does all three, including distinguishing station types and routing to alternative tools, so an agent has enough to call it 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%, so the baseline is 3. The description adds substantial meaning for the 'expand' parameter by defining each enum value (details dates, sensors with elevations, floodlevels thresholds, etc.) and tying sub-resources to station types—information not present in the schema's terse expand description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the specific verb ('Get') and resource ('a NOAA station's full metadata record') and enumerates the fields returned. It distinguishes the tool from siblings by directing datum requests to noaa_get_station_datums and harmonic constituent requests to noaa_get_harmonic_constituents.

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?

It gives explicit context: 'Use this before requesting data to confirm what the station actually collects,' and names the correct alternative tools for datum values and harmonic constituents. The expand parameter is framed as optional and its availability varies by station type, so an agent knows when to invoke it.

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