AirNow MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose based on the combination of data type (e.g., contour maps, observations, forecasts), pollutant (e.g., ozone, PM2.5), location method (e.g., bounding box, lat-long, zip code), and time frame (e.g., current, historical). There is no overlap in functionality, making it easy for an agent to select the correct tool for a specific query.
Naming Consistency5/5
All tool names follow a consistent verb-noun pattern with hyphens, starting with 'get-' and including descriptive details like data type, location method, and parameters. This uniformity enhances readability and predictability, allowing agents to easily understand and navigate the tool set.
Tool Count5/5
With 10 tools, the server is well-scoped for air quality data retrieval, covering key operations such as current and historical observations, forecasts, and contour maps across different location methods. Each tool serves a specific purpose without redundancy, making the count appropriate for the domain.
Completeness5/5
The tool set provides comprehensive coverage for air quality data, including current and historical observations, forecasts, and contour maps for ozone and PM2.5, with multiple location inputs (lat-long, zip code, bounding box). There are no obvious gaps, as it supports all major data retrieval needs in this domain.
Average 3.1/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool returns ('current AQI values and categories') but lacks critical behavioral details: it doesn't mention error handling (e.g., what happens if no reporting area is found), rate limits, authentication needs, or response format implications. The 'distance' parameter description in the schema hints at fallback behavior, but the tool description itself doesn't disclose this.
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?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place with no redundancy or unnecessary elaboration. It's appropriately sized for a straightforward lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'AQI values and categories' means, the structure of returned data, or error conditions. For a tool with 4 parameters and no structured output documentation, more context about behavior and results is needed.
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 description coverage is 100%, so parameters are fully documented in the schema. The description adds no parameter-specific information beyond implying latitude/longitude are required inputs. It doesn't explain parameter interactions, default values, or provide examples beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get current AQI values and categories for a reporting area by latitude and longitude.' It specifies the verb ('Get'), resource ('current AQI values and categories'), and key input method ('by latitude and longitude'). However, it doesn't explicitly differentiate from siblings like 'get-current-observations-by-reporting-area-by-zip-code' beyond the input method difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get-forecast-by-lat-long' for forecasts or 'get-historical-observations-by-reporting-area-by-lat-long' for historical data. There's no context about use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While it mentions what the tool returns ('current AQI values and categories'), it doesn't describe important behavioral aspects like error handling (what happens with invalid zip codes), rate limits, authentication requirements, or whether this is a read-only operation. The description is minimal and leaves key behavioral questions unanswered.
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 single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately front-loaded with the main purpose. However, given the tool's complexity and lack of annotations, it might be too concise at the expense of needed behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and multiple sibling alternatives, the description is insufficiently complete. It doesn't explain what 'reporting area' means in practice, doesn't clarify the relationship between zip codes and reporting areas, and provides no information about the response structure or format options despite the format parameter being required.
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?
With 100% schema description coverage, the input schema already provides comprehensive documentation for all three parameters. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions 'by Zip code' which aligns with the zipCode parameter but provides no additional context about parameter usage, relationships, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get current AQI values and categories') and target resource ('for a reporting area by Zip code'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its closest sibling 'get-current-observations-by-reporting-area-by-lat-long', which performs the same function but uses latitude/longitude instead of zip code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools available (including forecast tools, historical observations, and lat-long variants), there's no indication of when zip code lookup is preferred over lat-long or when current observations are appropriate versus forecasts or historical data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves forecasted AQI data but lacks details on permissions, rate limits, data freshness, error handling, or response format. This is inadequate for a tool with potential external API calls and data sensitivity.
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 single, efficient sentence that front-loads key information (get forecast, AQI, by Zip code). It avoids redundancy but could be slightly more structured by separating current vs. historical aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain return values (e.g., AQI categories, timestamps), error conditions, or dependencies like API availability. For a tool with environmental data implications, this leaves significant gaps for an AI agent.
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 description coverage is 100%, so the schema fully documents all parameters (date, distance, format, zipCode). The description adds no additional parameter semantics beyond implying AQI-related data, which doesn't compensate for schema completeness. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('forecasted AQI values and categories'), and the target ('by Zip code'), with specificity about current/historical data. However, it doesn't explicitly differentiate from sibling tools like 'get-forecast-by-lat-long' or 'get-current-observations-by-reporting-area-by-zip-code', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-forecast-by-lat-long' or observation-based tools. It mentions 'current or historical' but doesn't specify criteria for choosing between them or exclusions, leaving the agent without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving 'historical AQI values and categories' but fails to describe key behaviors: whether this is a read-only operation, potential rate limits, error handling (e.g., if no reporting area is found), or the structure of the returned data. The description is minimal and lacks operational context.
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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It does not address behavioral aspects like data format details, error scenarios, or how the 'distance' parameter affects results, leaving significant gaps for an agent to understand proper usage and expectations.
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?
The description does not add any parameter-specific information beyond what is already detailed in the input schema, which has 100% coverage with clear descriptions for all parameters. Since the schema fully documents the parameters, the baseline score of 3 is appropriate, as the description provides no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get historical AQI values and categories') and the target ('for a reporting area by latitude and longitude'), making the purpose understandable. However, it does not explicitly differentiate this tool from its sibling 'get-historical-observations-by-reporting-area-by-zip-code', which serves a similar purpose but uses a different input method (zip code vs. lat/long).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as the sibling tools for current observations, forecasts, or historical data by zip code. It lacks explicit context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based on parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but lacks critical details: it doesn't specify output format beyond 'AQI values and categories', mention rate limits, authentication requirements, error handling, or data freshness. The description implies a read-only operation but doesn't explicitly confirm safety or potential side effects.
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?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by specifying the action, data type, and target, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 4-parameter tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like data sources, accuracy, limitations (e.g., date ranges), or output structure. For a tool that likely returns structured environmental data, more context is needed to use it effectively without trial and error.
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 description coverage is 100%, so parameters are fully documented in the input schema. The description adds no additional parameter semantics beyond implying Zip code and date usage. It doesn't explain interactions between parameters (e.g., how distance affects results) or provide examples beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get historical AQI values and categories') and target ('for a reporting area by Zip code'), which is specific and actionable. However, it doesn't differentiate from sibling tools like 'get-historical-observations-by-reporting-area-by-lat-long' or 'get-current-observations-by-reporting-area-by-zip-code', which would require mentioning temporal scope (historical vs current) or input method (Zip code vs lat/long).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools or contextual factors like data availability, performance considerations, or prerequisites. Users must infer usage from the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It states what the tool does but doesn't describe response format, pagination, rate limits, authentication requirements, or error conditions. For a data retrieval tool with 9 parameters, this leaves significant behavioral aspects undocumented.
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?
The description is a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for the tool's complexity and front-loads the essential information. Every word earns its place in conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex data retrieval tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'observations' contain, the data format returned, or how results are structured. The description should provide more context about the nature of the observations and typical use cases given the tool's complexity.
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 description coverage is 100%, so the schema fully documents all 9 parameters. The description adds no parameter-specific information beyond what's in the schema. This meets the baseline of 3 since the schema does the heavy lifting, but the description provides no additional context about parameter interactions or usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('observations by monitoring site') with geographic bounding scope. It distinguishes from siblings like contour maps, forecasts, and reporting-area tools by specifying monitoring sites and bounding box. However, it doesn't explicitly contrast with similar tools like 'get-historical-observations-by-reporting-area-by-lat-long' beyond the obvious site vs reporting-area difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites, typical use cases, or comparisons to sibling tools. While the name implies geographic bounding box filtering, there's no explicit 'when-not' or alternative tool recommendations for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states the output format (KML) and temporal scope (current/historical), but doesn't disclose authentication needs, rate limits, data freshness, error conditions, or what 'contour maps' specifically contain. For a data retrieval tool with zero annotation coverage, this leaves significant gaps.
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?
The description is a single, well-structured sentence with zero wasted words. It front-loads the core purpose and efficiently includes key details (Ozone, KML, bounding box). Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with full schema coverage but no annotations or output schema, the description is minimally adequate. It covers the basic purpose and output format, but for a tool that retrieves environmental data with temporal and spatial parameters, more context about data sources, update frequency, or typical use cases would be helpful.
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 description coverage is 100%, so the schema fully documents all three parameters. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't clarify 'bbox' format or 'date' interpretation). Baseline score of 3 is appropriate when the schema does all the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), resource ('Ozone contour maps'), format ('in KML'), and scope ('by geographic bounding box'). It distinguishes from some siblings by specifying 'Ozone' (vs. PM2.5 or combined) and 'geographic bounding box' (vs. other location methods), but doesn't explicitly differentiate from all similar tools like 'get-contour-maps-by-bounding-box-combined-ozone-pm25'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'current or historical' but doesn't explain when to choose this over other observation or forecast tools in the sibling list, nor does it specify any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'current or historical forecasted AQI values and categories' but doesn't explain what 'forecasted' entails (e.g., time range, accuracy), how 'reporting area' is determined, or any limitations like rate limits or authentication needs. For a tool with no annotations, this is a significant gap in transparency.
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?
The description is a single, efficient sentence that front-loads the core functionality without unnecessary words. It directly states what the tool does, making it easy to parse and understand quickly. Every part of the sentence contributes to clarifying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema, no annotations), the description is incomplete. It covers the basic purpose but lacks usage guidelines, behavioral details, and output information. While the schema handles parameters well, the description doesn't compensate for missing annotations or output schema, leaving gaps in overall context.
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?
The description adds minimal value beyond the input schema, which has 100% coverage with detailed parameter descriptions. It implies latitude/longitude are used to locate a 'reporting area' and mentions 'current or historical' (hinting at the 'date' parameter), but doesn't elaborate on parameter interactions or semantics. With high schema coverage, the baseline is 3, and the description doesn't significantly enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get current or historical forecasted AQI values and categories for a reporting area by latitude and longitude.' It specifies the verb ('Get'), resource ('forecasted AQI values and categories'), and mechanism ('by latitude and longitude'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from siblings like 'get-forecast-by-zip-code' or 'get-current-observations-by-reporting-area-by-lat-long', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'get-forecast-by-zip-code' for zip-based queries or 'get-current-observations-by-reporting-area-by-lat-long' for non-forecast data, nor does it specify prerequisites or exclusions. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions output format (KML) and data type (current/historical PM2.5), but lacks critical behavioral details such as rate limits, authentication needs, data freshness, error handling, or what 'contour maps' entail (e.g., resolution, units). For a tool with no annotations, this is insufficient.
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?
The description is a single, efficient sentence that front-loads key information (action, resource, format, method). Every word contributes directly to the tool's purpose without redundancy or fluff, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool that fetches environmental data (which may involve complexities like data latency or accuracy), the description is incomplete. It lacks details on output structure, error cases, performance expectations, or how results integrate with sibling tools, leaving significant gaps for an AI agent.
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 description coverage is 100%, providing detailed parameter documentation. The description adds minimal value beyond the schema, only implying that parameters define the bounding box and date for PM2.5 data. No additional semantics or usage context are provided, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), resource ('PM2.5 contour maps'), and format ('in KML'), with geographic bounding box as the method. It distinguishes from some siblings by specifying PM2.5 (vs. ozone or combined pollutants) and bounding box method, though not all sibling distinctions are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for current or historical PM2.5 contour maps via bounding box, but lacks explicit guidance on when to choose this over alternatives like sibling tools for ozone, combined pollutants, or different geographic methods (e.g., zip code, lat-long). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'current or historical' data and KML format, but lacks details on permissions, rate limits, data freshness, or error handling, which are critical for a data retrieval tool with no structured safety hints.
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?
The description is a single, efficient sentence that front-loads key information (action, resource, format, method) with no wasted words, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description adequately covers the tool's purpose and basic usage but lacks behavioral details like response format, pagination, or error cases, making it minimally viable but incomplete for full agent guidance.
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 description coverage is 100%, so the schema fully documents parameters. The description adds context by specifying 'combined Ozone and PM2.5' and 'KML', but does not provide additional semantic details beyond what the schema already covers, meeting the baseline for high coverage.
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 clearly states the action ('Get'), the resource ('combined Ozone and PM2.5 contour maps'), the format ('KML'), and the method ('by geographic bounding box'), distinguishing it from siblings that handle single pollutants or different data types like observations or forecasts.
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?
It implies usage for current or historical contour maps via bounding box, but does not explicitly state when to use this tool versus alternatives like sibling tools for single pollutants or other data retrieval methods, leaving some ambiguity in sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![airnow-mcp-server MCP server](https://glama.ai/mcp/servers/prsantos-com/airnow-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/prsantos-com/airnow-mcp-server)

Score Badge

Copy to your README.md:

[![airnow-mcp-server MCP server](https://glama.ai/mcp/servers/prsantos-com/airnow-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/prsantos-com/airnow-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/prsantos-com/airnow-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server