epa-mcp-server

Search Superfund Sites

epa_superfund_search_sites

Read-onlyIdempotent

Superfund: Search Superfund (CERCLA/SEMS) sites by location or NPL listing status. Returns site name, EPA site ID, NPL status (listed/not listed/proposed), cleanup status, coordinates, and county FIPS code. Accepts either state/city/ZIP or latitude+longitude+radius for proximity searches, ordered nearest first. Proximity searches exhaust candidate pages within a shared 50-second deadline; narrow the radius or add filters if the search times out. Use for "are there Superfund sites near X" questions.

Input Schema

Name	Required	Description	Default
`city`	No	City name (partial match within state, case-insensitive). Punctuation is matched as written ("St. Louis", "Coeur d'Alene").
`limit`	No	Maximum number of sites to return (1–200)
`state`	No	2-letter US state abbreviation to filter sites
`latitude`	No	Latitude for proximity search (use with longitude and radius_miles)
`zip_code`	No	5-digit ZIP code to filter sites
`longitude`	No	Longitude for proximity search (use with latitude and radius_miles)
`npl_status`	No	Filter by NPL (National Priorities List) status: listed=final NPL, not-listed=not on NPL, proposed=proposed for listing, all=include all	all
`radius_miles`	No	Search radius in miles from the given coordinates. Required when using latitude+longitude.

Output Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`sites`	No	Matching Superfund sites
`notice`	No	Present when the result limit omits nearby sites or a non-proximity punctuated city filter reaches its page limit. Explains which matching sites were not returned.
`message`	No	Recovery hint when no sites are found. Absent when sites are returned.
`totalCount`	No	Number of sites returned (may be less than available if limit applied)

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 24, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower, yet the description still adds real behavior: the returned field set, nearest-first ordering for proximity queries, and a 50-second shared deadline with mitigation advice. That timeout budget is operationally valuable and appears nowhere in the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with what the tool is and what it returns, then the two input modes, then the timeout caveat. Every sentence carries information; there is no filler or restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter read-only search with a full schema and an output schema, the description covers purpose, inputs, ordering, and failure behavior. Listing return fields is slightly redundant given the output schema exists, but nothing an agent needs to call it correctly is missing.

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%, so baseline is 3, but the description adds the either/or mode contract (state/city/ZIP versus latitude+longitude+radius) that governs which parameters must be combined, which the schema only hints at per-field. That combination semantics is genuinely additive.

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?

Specific verb (Search) plus resource (Superfund/CERCLA/SEMS sites) plus the two search axes (location, NPL status). The scope is clearly distinct from the EPA siblings, which cover air, ECHO facilities, TRI releases, and 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?

Explicitly states the triggering question form ("are there Superfund sites near X") and gives remedial guidance when a proximity search times out (narrow radius, add filters). It does not name when to prefer a sibling tool instead, but the domain is non-overlapping enough that this is a minor gap.

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

All epa-mcp-server tools Inspect

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.