epa-mcp-server

Get Air Quality Index

epa_airnow_get_conditions

Read-onlyIdempotent

AirNow: Get current AQI observations or the issued AQI forecast for a US location from the AirNow API. Provide either zip_code or both latitude and longitude. Current mode returns the latest hourly NowCast AQI for each pollutant (PM2.5, ozone, PM10) from the closest monitor within 50 miles, with the monitor site name, site ID, and reporting agency; pollutants in one reporting area can come from different monitors. Forecast mode returns every day the reporting area's agency has issued (typically one to five), each with the AQI category, an action-day flag, and the issue date, plus the agency's forecast discussion when one exists; some agencies forecast a category without an AQI number. In forecast mode, set forecast_date to keep only the forecast valid on that date; current mode rejects it. Data are preliminary — suitable for awareness, not regulatory, trend, or enforcement decisions. Responses are cached for ~1 hour.

Input Schema

Name	Required	Description	Default
`mode`	No	Data mode: "current" for the latest hourly observations, "forecast" for every forecast day the reporting area has issued	current
`latitude`	No	Latitude in decimal degrees (use with longitude instead of zip_code)
`zip_code`	No	5-digit US ZIP code for the location
`longitude`	No	Longitude in decimal degrees (use with latitude instead of zip_code)
`forecast_date`	No	Forecast mode only (rejected in current mode): keep just the forecast valid on this date (YYYY-MM-DD). Omit to get every issued forecast day. When no issued day matches, the result is empty and its message lists the issued dates.

Output Schema

Name	Required	Description
`mode`	No	Data mode used: "current" or "forecast"
`error`	No	Present when the call failed. Absent on success.
`message`	No	Why the result is empty: AirNow's own explanation, the issued forecast dates when forecast_date matched none, or a coverage hint. Absent when data is returned.
`attribution`	No	Credit to the reporting or forecasting agencies and the U.S. EPA AirNow program, with the preliminary-data notice. Reproduce it when passing this data on.
`observations`	No	AQI observation or forecast records grouped by reporting area

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover readOnly/idempotent/openWorld, but the description adds substantial behavior beyond them: the 50-mile nearest-monitor radius, per-pollutant monitor sourcing within one reporting area, typical forecast day counts (one to five), agencies that report a category without an AQI number, empty results with issued dates in the message, and a ~1 hour cache. The preliminary-data caveat is unusual and valuable.

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?

Front-loaded with purpose and location requirements, then modes, then caveats; every sentence carries information. It is a dense single paragraph of roughly 150 words, which is on the long side and would scan better split into purpose / location / modes / caveats.

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?

Despite an output schema existing, the description explains what each mode returns and its known quirks (missing AQI numbers, multiple monitors per area, empty-result messaging). Combined with the data-quality warning, an agent has everything needed to call and interpret this tool correctly.

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 coverage is 100%, so the baseline is 3. The description goes past the schema by explaining that forecast_date is rejected in current mode and by clarifying that omitting it returns every issued day, adding consequence-level meaning rather than restating field 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?

States a specific verb (get), resource (current AQI observations or issued AQI forecast), and source (AirNow API) with the geographic scope (US location). Sibling tools all belong to other EPA programs (ECHO, EJScreen, TRI, Superfund, water), so the AirNow framing alone distinguishes it.

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?

Gives explicit location rules (zip_code OR both latitude and longitude), explicit mode selection guidance, and an explicit exclusion: 'suitable for awareness, not regulatory, trend, or enforcement decisions.' It also states that current mode rejects forecast_date, removing a likely misuse path.

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.