Skip to main content
Glama

GroundTruth - Environmental Records

Find federal environmental records near an address

environment_near
Read-onlyIdempotent

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.

Input Schema

NameRequiredDescriptionDefault
latNoLatitude (US)
lonNoLongitude (US; negative except Guam, NMI and the western Aleutians)
addressNoUS street address incl. city/state (alternative to lat/lon)
radius_kmNoSearch radius in km (default 10, max 50)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / lat / maximum
      Added value: +90
    • addedInput schema / properties / lat / minimum
      Added value: +-90
    • changedInput schema / properties / lon / description
      Previous value: -"Longitude (US, negative)"New value: +"Longitude (US; negative except Guam, NMI and the western Aleutians)"
    • addedInput schema / properties / lon / maximum
      Added value: +180
    • addedInput schema / properties / lon / minimum
      Added value: +-180
    • addedInput schema / properties / radius_km / maximum
      Added value: +50
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness4/5

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.

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

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources