Get the air quality forecast for a ZIP code.
Returns forecast AQI values and health categories for upcoming days,
typically covering today and the next 1-2 days.
Args:
zip_code: US ZIP code (e.g. '20001').
| Name | Required | Description | Default |
|---|---|---|---|
| zip_code | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the return content (forecast AQI values and health categories) and a behavioral caveat ('typically covering today and the next 1-2 days'), which is useful context for a read-only retrieval tool.
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 brief and front-loaded, with the core purpose stated first, followed by a concise return summary and a clear Args section. Every sentence adds value, with no redundancy or 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?
This is a simple one-parameter tool with an output schema present, so the description need not explain return structures. It covers the parameter format, the nature of the forecast, and the typical horizon, making it complete for the tool's complexity.
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?
The schema only defines zip_code as a string with no description. The tool description adds essential meaning by specifying it is a US ZIP code and providing a concrete example ('20001'), fully compensating for the 0% schema coverage.
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 uses a specific verb ('Get') and resource ('air quality forecast') and identifies the ZIP code input, clearly distinguishing it from sibling tools like get_current_aqi, which covers current conditions. The forecast horizon ('upcoming days') further differentiates its purpose.
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 implies this tool is for forecasting rather than current conditions, saying it returns values for upcoming days. It does not explicitly name alternatives or exclusions, but the context is sufficient for a user to select it when they need a forecast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The two air quality tools (current and forecast) are clearly separated by time frame, and the historical summary is distinct. The two toxics tools (Superfund and TRI) are both state-based hazard listings but differ in content (cleanup sites vs. reporting facilities). Minor potential confusion between Superfund and TRI, but descriptions clarify.
All tools use the consistent 'get_' prefix followed by descriptive noun phrases in snake_case. The pattern is uniform across the set.
Five tools cover the server's stated scope of air quality and toxics without redundancy. Each tool addresses a distinct data need, and the count is within the ideal 3-15 range.
The air quality surface covers current, forecast, and annual historical data. The toxics surface covers site and facility listings. Missing are detailed facility-level emissions or site-specific cleanup data, but core queries are supported.