Skip to main content
Glama

GroundTruth - Environmental Records

by ai.agentlookups
OverviewDiscussionsAdmin

Look up public water systems for an area

drinking_water
Read-onlyIdempotent

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.

Input Schema

NameRequiredDescriptionDefault
latNoLatitude (US)
lonNoLongitude (US; negative except Guam, NMI and the western Aleutians)
cityNoCity served (optional)
stateNoTwo-letter state code, e.g. MD (with county and/or city; not sent with address or lat/lon)
countyNoCounty name (optional), e.g. Kings, Prince George's County, Richmond city
addressNoUS street address incl. city/state (alternative to state or lat/lon)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / address
      Added value: +{
+  "description": "US street address incl. city/state (alternative to state or lat/lon)",
+  "type": "string"
+}
    • changedInput schema / properties / county / description
      Previous value: -"County name (optional)"New value: +"County name (optional), e.g. Kings, Prince George's County, Richmond city"
    • addedInput schema / properties / lat
      Added value: +{
+  "description": "Latitude (US)",
+  "maximum": 90,
+  "minimum": -90,
+  "type": "number"
+}
    • addedInput schema / properties / lon
      Added value: +{
+  "description": "Longitude (US; negative except Guam, NMI and the western Aleutians)",
+  "maximum": 180,
+  "minimum": -180,
+  "type": "number"
+}
    • changedInput schema / properties / state / description
      Previous 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)"
    • removedInput schema / required
      Removed value: -[
-  "state"
-]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All GroundTruth - Environmental Records toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources