Federal environmental records near any US location, with dates and provenance; never a safety score.
Scored across 4 tools
The four tools target distinct domains: broadband, drinking water, nearby EPA records, and composite location scores, so selection is usually clear. However, environment_near and location_scores overlap on Superfund/contamination signals, requiring the agent to distinguish whether the user wants records or scores.
All names use snake_case and are readable, but there is no consistent verb_noun or noun_action pattern: two are plain noun phrases, one uses an awkward _near suffix, and one is a pluralized noun phrase. The inconsistency is minor but makes the surface less predictable.
Four tools is well within the 3-15 range and each bundles a meaningful, non-redundant capability for a location-profile server. The broad scope of each tool explains the low count without feeling thin.
The set covers broadband, drinking water, nearby EPA records, and aggregate scores, but offers no drill-down into the underlying data for scored layers such as air quality, crime, schools, or hazards. Users can see scores and nearby records but cannot retrieve detailed records for several scored layers, leaving notable gaps.
Fixed broadband availability for a US location from the FCC Broadband Data Collection (BDC), counted per 2020 Census block: each provider and technology the FCC data lists in the block, with advertised maximum download and upload tiers in Mbps and how many of the block's locations each covers (residential and business-only counts). FCC data as of 2025-12-31 (release D25_19oct2026). Wired and fixed wireless service comes first; satellite service is listed last, in its own section. Where a point is in no Census block with FCC data, counts are for the surrounding H3 cell. A block where the FCC records no locations (often a park, a plaza or a street) lists no providers; the building's own address finds the block it sits in. Speeds are advertised maximums reported by providers, not measured speeds. The FCC data has no street addresses, so it cannot confirm service at one house. Input is either a street address (geocoded by the US Census geocoder) or lat/lon coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (US) | |
| lon | No | Longitude (US; negative except Guam, NMI and the western Aleutians) | |
| address | No | US street address incl. city/state (alternative to lat/lon) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds massive behavioral context beyond the simple readOnly/idempotent annotations. It specifies the data nature (maximum advertised speeds, not measured), the data source age (2025-12-31), and the organizational structure of the results (Wired/Fixed Wireless before Satellite).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly detailed, which is unavoidable given the complexity of the underlying FCC data, but it is well-structured. Each sentence contributes crucial, non-redundant information (data source, resolution, limitations) without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is exceptionally complete for a complex, data-intensive external tool. It addresses potential user confusion regarding speeds (maximum vs. measured), resolution (census block vs. H3 cell), and data limitations (no service confirmation at single houses).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema coverage is 100%, the description does not need to explain individual parameters. However, it provides vital semantic context regarding input handling, specifying that the input can be a geocoded address or lat/lon, adding functional depth to the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function (List FCC broadband availability) and specifies the resource (FCC Broadband Data Collection) and scope (US location census blocks). It distinguishes itself from sibling tools by focusing specifically on the broadband data availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it does not explicitly state 'when to use this vs. siblings,' it provides comprehensive usage guidance by defining the operational boundaries and limitations of the data. It clarifies how address input is processed and when H3 cells are used for resolution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public water systems for a US location, from EPA's quarterly drinking-water data (SDWA; GroundTruth checks for a new quarter monthly), with health-based violation summaries, counts of missed or late required tests (monitoring and reporting violations), and each system's latest lead 90th percentile. Input is a street address or lat/lon coordinates (the US Census geocoder gives the county and place, and the point is checked against EPA's Community Water System Service Area Boundaries; a point outside every boundary returns no systems and a message that the home may use a private well or the map may miss its system), or a two-letter state with an optional county and/or city. Each system carries match_basis: service_area_boundary, zip, city, county or state. Some of EPA's boundaries come from states and water systems and the rest are modeled by EPA, so matching is approximate; the user's water bill names their actual utility. Systems are listed by population served, and the order does not say which system serves a given home.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (US) | |
| lon | No | Longitude (US; negative except Guam, NMI and the western Aleutians) | |
| city | No | City served (optional) | |
| state | No | Two-letter state code, e.g. MD (with county and/or city; not sent with address or lat/lon) | |
| county | No | County name (optional), e.g. Kings, Prince George's County, Richmond city | |
| address | No | US street address incl. city/state (alternative to state or lat/lon) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is read-only, idempotent, non-destructive, and open-world. The description adds substantial behavioral detail beyond that: EPA quarterly data, monthly GroundTruth checks, approximate boundary matching, the meaning of match_basis, and the behavior when a point falls outside every service-area boundary, including the private-well / map-miss message. It also warns that systems are ordered by population served and that the order does not indicate which system serves a specific home.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense single paragraph, but it is front-loaded with the core purpose and returned data before moving into input modes and matching caveats. Every major sentence contributes useful context, though the paragraph could be split for easier scanning. It is appropriately sized for a tool with six optional geographic parameters and nuanced real-world matching behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining what is returned, and it does so with specific fields and caveats. Combined with annotations that cover the safety and openness profile, the description gives an agent enough to call the tool correctly and interpret the result, including the no-match case and the limits of approximate matching.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline would already be 3. The description adds useful semantics by explaining the alternative input modes and how address or lat/lon is geocoded against Census and EPA service-area boundaries. It also clarifies the meaning of state/county/city combinations and the match_basis values, which goes beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: looking up public water systems for a US location from EPA drinking-water data. It also names the exact payload: health-based violation summaries, monitoring/reporting violation counts, and latest lead 90th percentile. This is far more informative than the title alone and makes the tool clearly distinct from the sibling tools, which cover broadband, environment, and location scores rather than water systems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains the accepted input modes: a street address, lat/lon coordinates, or a two-letter state with optional county/city. It also gives important matching context, noting that boundary matching is approximate and that the water bill names the actual utility. It does not explicitly define when to choose this tool over a sibling, but the sibling tools are not close substitutes, so the context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Environmental records within a radius of a US location, from GroundTruth's monthly snapshot of three EPA datasets: National Priorities List (Superfund) sites, facilities from the newest Toxics Release Inventory (TRI) reporting year, and active facilities with a current significant-noncompliance or high-priority-violation flag in EPA ECHO. Each record carries its distance, and provenance gives each dataset's source and snapshot date (as_of). A Superfund distance runs to the nearer of the area EPA maps for the site (distance_to: epa_site_boundary, 0 with inside_site_boundary true inside it) and the one point EPA lists for the site (distance_to: epa_listed_point); each record gives both. Where EPA maps no area, a site that stretches out (a canal, a river, an underground plume) can reach closer than its point. Input is either a street address (geocoded by the US Census geocoder) or lat/lon coordinates. Results are records, not a safety assessment. An empty list means the snapshot holds no such record within the radius. EPA holds other records this tool does not search (Superfund sites not on the NPL, earlier TRI years, facilities without a current noncompliance flag), and an empty result does not mean the area is free of contamination.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (US) | |
| lon | No | Longitude (US; negative except Guam, NMI and the western Aleutians) | |
| address | No | US street address incl. city/state (alternative to lat/lon) | |
| radius_km | No | Search radius in km (default 10, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds substantially: monthly snapshot provenance with per-dataset as_of dates, the dual distance semantics (EPA site boundary vs listed point, with inside-boundary flag), and a careful disclaimer that results are records, not a safety assessment. It also preempts the false-negative reading of an empty result, which is the main behavioral risk for a spatial search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Scope and datasets are front-loaded in the first sentence, followed by output semantics and caveats in a logical order. It is dense and a couple of sentences about Superfund boundary geometry could be tightened, but nearly every clause carries operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly takes on the burden of describing return values: per-record distance, both distance variants, and provenance with source and as_of. Combined with the input-mode and empty-result explanations, an agent has everything needed to call and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents lat, lon, address and radius_km including the default and 50 km cap. The description only adds the geocoding back end (US Census geocoder) and the address/lat-lon either-or relationship, which is modest added value over the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (find/list) and resource (federal environmental records within a radius of a US location) and enumerates exactly which three EPA datasets are covered. This is unmistakably distinct from the siblings broadband_availability, drinking_water and location_scores without needing their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the two input modes (street address geocoded by Census, or lat/lon), the meaning of an empty list, and explicitly excludes records the tool does not search (non-NPL Superfund sites, earlier TRI years, unflagged facilities). It stops short of naming a sibling or stating a positive 'use X instead when...' routing rule, so it is clear context rather than full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Layer scores for a US location: school quality, natural hazards, groundwater contamination, Superfund proximity, air quality, highway noise, walkability, crime, and climate pleasantness (pleasant days/year). Scores are 0-1 with 1.0 = favorable; null = cannot score that layer here. The scores are model estimates drawn from public datasets, not safety ratings. no_coverage marks a layer that is null because this location lies outside that layer's data, and caveats. says why. When a layer's number has limits the score alone does not show (a proxy, partial source data), caveats. states them. Superfund proximity weighs each cleanup site by the nearer of the area EPA maps for it and the one point EPA lists for it; where EPA maps no area, a site that stretches out (a canal, a plume) can be closer than the score reflects. The scores are not a safety assessment, and an absence of adverse signals is not a clean bill of health. Coverage: Superfund/toxic-release proximity national; air quality, groundwater, and natural hazards a San Francisco Bay Area grid (lat 37.0 to 38.6, lon -122.8 to -121.4, which also takes in Sacramento), null elsewhere; highway noise Bay Area; walkability California; schools all 50 states and DC (2023-2025 results); climate CONUS (gridMET 4km, 2015-2024); Alaska, the Florida Keys, Hawaii, Puerto Rico and the US Virgin Islands (Daymet V4, 2011-2020); within 40 km of 3 NOAA weather stations in American Samoa, the Northern Mariana Islands and Guam (2016-2025); null elsewhere; crime police incident feeds inside the city limits of San Francisco; Oakland; Chicago; New York City; Los Angeles; Dallas; Washington, DC; and Kansas City, Missouri only. School scores draw on the Stanford Education Data Archive (SEDA), whose terms require naming it as the source: Reardon, S. F., Ho, A. D., Shear, B. R., Fahle, E. M., Kalogrides, D., Saliba, J. (2024). Stanford Education Data Archive (Version 5.0). [https://purl.stanford.edu/cs829jn7849] [https://doi.org/10.25740/cs829jn7849] (also in citations.school_quality). Input is either a street address (geocoded by the US Census geocoder) or lat/lon coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (US) | |
| lon | No | Longitude (US; negative except Guam, NMI and the western Aleutians) | |
| address | No | US street address incl. city/state (alternative to lat/lon) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only, idempotent annotations, the description discloses that scores are model estimates from public datasets, not safety ratings, and explains null handling via no_coverage and caveats.<layer>. It also details coverage limits, Superfund proximity weighting, and school-data sourcing, which are substantial behavioral disclosures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the key purpose, but it is extremely long and includes dense coverage lists, full citations, and caveat implementation details. Much of this is relevant but could be condensed or moved to output documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the lack of an output schema, and the many coverage-limited layers, the description is sufficiently complete. It explains score ranges, null semantics, caveats, source limitations, and input options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the lat, lon, and address parameters are already well documented. The description adds that addresses are geocoded by the US Census geocoder and that address is an alternative to coordinates, but it does not clarify precedence if both are supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the resource and scope: layer scores for a US location across named domains such as schools, hazards, groundwater, and walkability. It is highly specific, but it does not explicitly differentiate itself from sibling tools like environment_near or drinking_water.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the detailed coverage notes and the statement that input is an address or lat/lon coordinates. However, the description never says when to choose this tool over broadband_availability, drinking_water, or environment_near, nor does it state any when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
drinking_water6 fields changedInput schema / properties / addressAdded value: +{
+ "description": "US street address incl. city/state (alternative to state or lat/lon)",
+ "type": "string"
+}Input schema / properties / county / descriptionPrevious value: -"County name (optional)"New value: +"County name (optional), e.g. Kings, Prince George's County, Richmond city"Input schema / properties / latAdded value: +{
+ "description": "Latitude (US)",
+ "maximum": 90,
+ "minimum": -90,
+ "type": "number"
+}Input schema / properties / lonAdded value: +{
+ "description": "Longitude (US; negative except Guam, NMI and the western Aleutians)",
+ "maximum": 180,
+ "minimum": -180,
+ "type": "number"
+}Input schema / properties / state / descriptionPrevious value: -"Two-letter state code, e.g. MD"New value: +"Two-letter state code, e.g. MD (with county and/or city; not sent with address or lat/lon)"Input schema / requiredRemoved value: -[
- "state"
-]due_diligencelocation_scoresbroadband_availabilitydue_diligence5 fields changedInput schema / properties / lat / maximumAdded value: +90Input schema / properties / lat / minimumAdded value: +-90Input schema / properties / lon / descriptionPrevious value: -"Longitude (US, negative)"New value: +"Longitude (US; negative except Guam, NMI and the western Aleutians)"Input schema / properties / lon / maximumAdded value: +180Input schema / properties / lon / minimumAdded value: +-180environment_near6 fields changedInput schema / properties / lat / maximumAdded value: +90Input schema / properties / lat / minimumAdded value: +-90Input schema / properties / lon / descriptionPrevious value: -"Longitude (US, negative)"New value: +"Longitude (US; negative except Guam, NMI and the western Aleutians)"Input schema / properties / lon / maximumAdded value: +180Input schema / properties / lon / minimumAdded value: +-180Input schema / properties / radius_km / maximumAdded value: +50due_diligencedrinking_waterenvironment_nearSearch EPA compliance, TRI, Superfund, drinking-water, EJScreen, and AirNow data.
Toxics Release Inventory, Superfund sites, air quality data, and AQI
Public hazard, water, weather and EPA data with source, age and licence on every reading.
Query US tap-water quality from the EPA's SDWIS records — by city, system, or contaminant.
Add one secure layer between your agents and this server.