gov-data-mcp

nhd-surface-water-404-screener

Screen any latitude/longitude against USGS NHDPlus HR surface water to flag Section 404/WOTUS jurisdiction likelihood, nearest streams, waterbody type, flow, and HUC codes.

Instructions

USGS NHD Surface Water & Section 404 Wetland Screener. Screen any lat/lon against USGS NHDPlus HR surface water. 94 fields: exact distance to the nearest perennial, intermittent and ephemeral reach, waterbody type and purpose, mean annual flow, stream order, HUC-8/10/12, a jurisdictional-likelihood call with its reasoning, and a Section 404/WOTUS flag. CHOOSE THIS for Clean Water Act §404 surface-water screening — streams, waterbodies and their relative permanence. For mapped wetland polygons use fws-wetlands-proximity-screener. Reads live from the official government source. Call describe-gov-data-tool (free) for a verified example input. COST AND SIDE EFFECTS: read-only with respect to the government source — it never writes to any external system — but each call starts a metered run on YOUR Apify account, billed $0.012 per Result ($12 per 1,000). Lower on paid Apify plans, down to $3.60 per 1,000. Nothing is charged when a run fails. Store page: https://apify.com/malonestar/nhd-surface-water-404-screener

Input Schema

Name	Required	Description
`assets`	Yes	Required. The list of sites to screen, in the standard [{lat, lon, label}] shape. Use decimal degrees (lon is negative in the USA). label is optional free text - it is echoed on every output row so you can join results back to your parcel list. Example: [{"lat":40.0143,"lon":-105.2829,"label":"Boulder CO parcel"}]. The four prefilled sites deliberately cover the range of outcomes: a creekside parcel 5 m from a perennial stream carrying 103 cfs (HIGH), a Louisiana site sitting inside an NHD swamp/marsh (HIGH, wetland-driven), an Arizona parcel inside a mapped desert wash (LOW - washes are reported but are not jurisdictional after Sackett), an upland Mojave parcel whose only nearby feature is an ephemeral reach (LOW), and an open-coast parcel at the mouth of Mobile Bay sitting on the Gulf of Mexico polygon (HIGH) - the coastal case that build 1.1.6 and earlier could not screen at all. Example: [{"lat":40.0143,"lon":-105.2829,"label":"Boulder CO - creekside redevelopment parcel"},{"lat":29.99091,"lon":-89.93323,"label":"New Orleans East LA - swamp/marsh adjacent site"},{"lat":33.42931,"lon":-111.98414,"label":"Tempe AZ - parcel inside a mapped desert wash"},{"lat":35.2,"lon":-115.9,"label":"Mojave NP CA - upland solar reference site"},{"lat":30.2481,"lon":-88.0783,"label":"Dauphin Islan…(truncated).
`maxResults`	No	Upper bound on the number of assets screened, and therefore on the number of dataset rows produced. One asset always produces exactly one row, including sites that turn out to be far from any mapped water. Clamped to 1-10000. Example: 100. Applied by default if omitted: 1000.
`radiusMeters`	No	How far around each site to look for NHD flowlines, waterbodies and water areas. 1000 m covers a typical Phase-I ESA adjacent-property review; widen to 3000 m for utility-scale solar, BESS or data-center siting. Clamped to 50-8000 m. Example: 1000. Applied by default if omitted: 1600.
`runBudgetSeconds`	No	Optional. One time budget for the whole run, shared by the live drift checks (at most 180 s of it) and every site. If hydro.nationalmap.gov is slow and the budget runs out, the sites not yet reached are returned as rows with failure_kind "deadline" and null counts/flags instead of the run dragging on. Leave empty to use max(240, 90 + 30 x number of assets) seconds. Clamped to 30-3500; the run also always stops before its Apify timeout. Example: 240.
`includeNonNetworkFlowlines`	No	Also query NHDPlus HR layer 4 (NonNetworkNHDFlowline) for isolated ditches, canals and disconnected reaches near the site. Leave on for a conservative wetland-delineation scope; turn off to save one request per asset. Note that layer 4 carries no NHDPlus value-added attributes, so a nearest reach found there has no mean annual flow, stream order or drainage area. Example: true.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.2.6Oct 7, 2026

changedInput schema / properties / runBudgetSeconds / description

Previous value: -"Optional. One time budget for the whole run, shared by the live drift checks (at most 90 s of it) and every site. If hydro.nationalmap.gov is slow and the budget runs out, the sites not yet reached are returned as rows with failure_kind \"deadline\" and null counts/flags instead of the run dragging on. Leave empty to use max(240, 90 + 30 x number of assets) seconds. Clamped to 30-3500; the run also always stops before its Apify timeout. Example: 240."New value: +"Optional. One time budget for the whole run, shared by the live drift checks (at most 180 s of it) and every site. If hydro.nationalmap.gov is slow and the budget runs out, the sites not yet reached are returned as rows with failure_kind \"deadline\" and null counts/flags instead of the run dragging on. Leave empty to use max(240, 90 + 30 x number of assets) seconds. Clamped to 30-3500; the run also always stops before its Apify timeout. Example: 240."

Changed1 schema field changedv1.1.3Sep 25, 2026

addedInput schema / properties / runBudgetSeconds

Added value: +{
+  "description": "Optional. One time budget for the whole run, shared by the live drift checks (at most 90 s of it) and every site. If hydro.nationalmap.gov is slow and the budget runs out, the sites not yet reached are returned as rows with failure_kind \"deadline\" and null counts/flags instead of the run dragging on. Leave empty to use max(240, 90 + 30 x number of assets) seconds. Clamped to 30-3500; the run also always stops before its Apify timeout. Example: 240.",
+  "maximum": 3500,
+  "minimum": 30,
+  "type": "integer"
+}

First observedv1.0.2Aug 20, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Despite annotations existing, the description adds substantial behavior not in them: the metered run on the caller's Apify account, exact pricing ($0.012 per Result, down to $3.60/1,000 on paid plans), no charge on failed runs, live reads from the official source, and deadline/failure semantics. This explains the readOnlyHint=false nuance (no writes to external systems, but the call does incur billed side effects) rather than contradicting it.

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?

Front-loaded with purpose and sibling routing, then cost/side effects last, and each sentence carries usable information (selection rule, alternative tool, pricing, store link). It is on the long side and the 94-field enumeration is dense, but little is genuinely redundant.

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?

With no output schema, the description compensates by describing the return content (distance metrics, waterbody type, flow, stream order, HUC levels, jurisdictional call and reasoning, 404/WOTUS flag) and failure rows ("failure_kind deadline" with null counts). Combined with full schema coverage and rich annotations, nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters (assets, maxResults, radiusMeters, runBudgetSeconds, includeNonNetworkFlowlines) are fully documented in the schema itself. The description adds output-field framing ("94 fields") but no parameter syntax or semantics beyond what the schema already provides, which is the expected baseline 3.

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?

Starts with a specific verb+resource ("Screen any lat/lon against USGS NHDPlus HR surface water") and enumerates the concrete outputs (distance to perennial/intermittent/ephemeral reaches, mean annual flow, stream order, HUC codes, jurisdictional-likelihood call, Section 404/WOTUS flag). It explicitly distinguishes itself from the sibling fws-wetlands-proximity-screener — streams/waterbodies vs mapped wetland polygons — so an agent can route without opening either schema.

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?

Gives an explicit selection rule ("CHOOSE THIS for Clean Water Act §404 surface-water screening") and names the alternative to use otherwise ("For mapped wetland polygons use fws-wetlands-proximity-screener"). It also points to describe-gov-data-tool for a verified example input, covering the pre-call discovery step.

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

Deploy Server

nhd-surface-water-404-screener

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools