Skip to main content
Glama
higherpass

mcp-usgs-water-data

by higherpass

get_instantaneous_values

Retrieve real-time and recent USGS streamflow, gage height, and water temperature readings from USGS gauges, filtered by site, state, HUC, bounding box, or county.

Instructions

Query the USGS Instantaneous Values (IV) service for real-time and recent surface-water and groundwater readings (streamflow, gage height, water temperature, etc). Data is available from 2007-10-01 onward.

Exactly one major filter is required to scope the query: sites, stateCd, huc, bBox, or countyCd. Providing zero, or more than one, is rejected. sites are USGS station numbers, typically 8 digits but 15 digits for many groundwater/well sites - pass them exactly as find_sites returns them, do not truncate or pad. Looking up a site by name (e.g. "Potomac River") is not supported by this tool; call find_sites first to resolve a name to a station number. bBox is an object {west, south, east, north} in decimal degrees - west/east are longitude (negative in the continental US), south/north are latitude (positive in the continental US) - with area (east-west)*(north-south) capped at 25 square degrees.

Date range: use either period (an ISO-8601 duration, e.g. P7D for the last 7 days) OR startDT/endDT for an absolute range - never both. endDT requires startDT. A query - dated or not - can return readings that are years old: a latest-value query returns the latest reading PER SENSOR, including sensors quietly gone dormant or decommissioned years ago, and a dated range can end early for one sensor while its siblings keep reporting through the end of the window. Every series carries stale, which is TRI-STATE, not a plain boolean: true (latest reading is more than 48 hours behind the query's reference time), false (it is not), or null (staleness could not be evaluated - no resolvable reference time, or no readings at all). Treat null as "not verified", never as current - check stale before reporting ANY value as current. discontinued explains WHY when USGS says so in the sensor's method description, but is not itself the signal to check - a sensor can go stale with no marker at all. When any returned series is stale or unevaluable, the response includes a note naming which ones, their reading dates, and how far behind they are.

This tool sends no siteStatus default, so USGS returns readings from ALL sites regardless of status - unlike find_sites, which defaults to siteStatus:"active". The same major filter can therefore return readings from sites find_sites didn't list. This is unrelated to stale/discontinued: a stale or decommissioned sensor sits at an otherwise-active site, so no siteStatus value filters it out.

Use mode:"summary" (not the default "values") for any window longer than a day. It returns {count, nonNullCount, min, max, mean, first, last} per series instead of every reading, avoiding truncation. mode:"values" returns up to maxValues (default 200, maximum 1000) of the MOST RECENT readings PER SERIES and sets truncated:true when more exist - a site with two sensors for the same parameter returns two series, each capped independently, so a 2-sensor site can still ship up to 2x maxValues readings total. checkResponseSize backstops the overall payload regardless. A single site over a single year already returns roughly 35,000 readings per series - windows beyond about a year should always use mode:"summary".

Returned values may be provisional (qualifier code "P") and subject to revision - present them as such, not as final measurements.

A series is omitted entirely, with no placeholder, when a site does not measure a requested parameter - a query for 3 parameterCd values can return fewer than 3 series. Match results on each series' variable.code; do not assume series[i] corresponds to parameterCd[i]. When this happens the result includes missingParameterCodes.

Don't know the 5-digit parameter code for what you want? Call list_common_parameter_codes first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hucNoHydrologic Unit Codes: either one 2-digit major HUC, or one or more 8-digit HUCs (up to 10 total). At most one 2-digit HUC per request; 8-digit HUCs can be combined freely.
bBoxNoBounding box in decimal degrees, as named fields (not a positional array) so west/south/east/north cannot be silently transposed. Area (east-west)*(north-south) must be <= 25 square degrees.
modeNovalues
endDTNo
sitesNoUSGS site numbers, typically 8 digits (e.g. "01646500"), but 15 digits for many groundwater/well sites (e.g. "334207084254801"). Pass them exactly as find_sites returns them; do not truncate or pad. Site-name lookup (e.g. "Potomac River") is not supported directly - use find_sites to resolve a name to a site number first.
periodNoISO-8601 duration for a relative window ending now, e.g. "P7D" for the last 7 days or "PT6H" for the last 6 hours. Cannot be combined with startDT/endDT.
startDTNo
stateCdNo
agencyCdNo
countyCdNo5-digit FIPS county codes (state FIPS + county FIPS), e.g. "24031" for Montgomery County, MD.
siteTypeNo
maxValuesNo
siteStatusNo
parameterCdNo
modifiedSinceNo
Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers richly. It discloses tri-state `stale` semantics, how `discontinued` works, siteStatus default behavior differing from siblings, per-sensor capping of maxValues, truncation behavior, omission of series without placeholders and the missingParameterCodes signal, provisional ('P') qualifier handling, and that dated queries return readings as old as the window regardless.

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?

Long but every sentence earns its place, covering genuinely non-obvious behavior (stale being tri-state, per-sensor capping, no placeholder for missing series, years-old dormant readings). Well organized with thematic paragraphs and a closing pointer to list_common_parameter_codes. None of the length is filler or tautology.

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?

For a 15-parameter tool with no output schema and no annotations, this is remarkably complete. It covers the cardinality constraint, date-range exclusivity, the two modes' payload implications, staleness semantics, series-to-parameter matching, and sibling-tool handoffs. The only mild gap is no mention of `modifiedSince` or `agencyCd`, but the schema covers those adequately.

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 only 33%, so the description must compensate, and it does extensively for the critical params: sites (exact digits, from find_sites, no truncation), bBox (named fields, decimal degree signs, area cap), period (ISO-8601 examples), mode (summary vs values tradeoffs). It adds meaning beyond schema for these. Some params like modifiedSince, agencyCd, siteType get no prose, but those have self-evident 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 begins with a specific verb-resource statement ('Query the USGS Instantaneous Values (IV) service for real-time and recent surface-water and groundwater readings') naming exact data types. It clearly differentiates from siblings: find_sites resolves names to station numbers (this tool does not), list_common_parameter_codes provides parameter codes. The scope is unambiguous.

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?

Exceptionally explicit: states the exactly-one-filter requirement (sites/stateCd/huc/bBox/countyCd) and that zero or more than one is rejected. Names alternatives explicitly ('call find_sites first', 'use list_common_parameter_codes first'). Distinguishes from find_sites' default siteStatus behavior and explains when summary mode should be used.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/higherpass/mcp-usgs-water-data'

If you have feedback or need assistance with the MCP directory API, please join our Discord server