gov-data-mcp

nhd-surface-water-404-screener

Screen any latitude/longitude against USGS NHDPlus HR to identify Clean Water Act Section 404 surface-water jurisdiction, with distance to streams, flow, and WOTUS flags.

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. 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

TableJSON 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 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.
`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.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.9/5.0

Behavior5/5

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

Despite annotations already indicating readOnlyHint=false, the description adds valuable nuance: it clarifies that the tool is read-only with respect to the government source but triggers a metered Apify run, discloses exact billing ($0.012/Result), mentions discounts, and explains failure behavior (nothing charged on run failure, rows with failure_kind 'deadline' when budget exhausted). This level of transparency goes far beyond what annotations provide and fully informs the agent of side effects and costs.

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 long, but every sentence carries relevant information. It is front-loaded with the core purpose and output enumeration, then addresses cost, alternatives, and parameter specifics. The formatting is dense but not repetitive. A slight penalty for wall-of-text presentation that could be parsed more quickly with headers or bullet points, but it is appropriately sized for the tool's complexity.

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 tool with 5 parameters, no output schema, and significant cost/side-effect nuances, the description is exceptionally complete. It explains the 94 output fields, the live source, failure modes, budget behavior, and even provides test sites covering the outcome range. Nothing an agent needs to invoke this tool correctly is missing, including how to interpret results and how to join them back to source data via the label field.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds significant semantics: it explains the [{lat, lon, label}] shape, gives concrete decimal-degree examples, clarifies defaults and clamping (e.g., maxResults default 1000, radiusMeters default 1600), offers use-case guidance (1000 m for Phase-I ESA, 3000 m for utility-scale), and explains the implications of includeNonNetworkFlowlines (layer 4 lacks NHDPlus value-added attributes). This adds meaning well beyond the raw schema definitions.

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 states the tool's purpose: 'Screen any lat/lon against USGS NHDPlus HR surface water.' It specifies the exact resource (NHDPlus HR), the verb (screen), and enumerates the 94 output fields. It also explicitly distinguishes itself from the sibling fws-wetlands-proximity-screener by naming the alternative and its condition. This is a model of purpose clarity.

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?

The description gives explicit when-to-use guidance: '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.' It also provides contextual advice for radiusMeters (typical ESA review vs. utility-scale projects) and explains the behavior of runBudgetSeconds. This leaves no ambiguity about when to select this tool over alternatives.

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