Integrates with Google Cloud's Environment APIs (Air Quality, Pollen, Weather) via a single API key, enabling retrieval of environmental data for given locations.
Provides tools for accessing Google Maps Platform Environment APIs, including air quality current conditions, forecast, and history; pollen forecast; and weather current conditions, forecast (days/hours), history, and public alerts.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@environment-mcp What's the current air quality in Tokyo?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server that proxies Google Maps Platform Environment APIs: Air Quality, Pollen, and Weather. Uses stdio transport and a single API key from the environment.
Node.js 20+
A Google Cloud project with billing enabled
APIs enabled: Air Quality API, Pollen API, Weather API (APIs & Services → Library)
An API key (APIs & Services → Credentials), with usage restricted appropriately for your setup
See the product setup guides for details: Air Quality, Pollen, Weather.
Related MCP server: Weather MCP Server
npm install
npm run buildSet the key (do not commit it):
export GOOGLE_MAPS_API_KEY="your-key"Alternatively use GOOGLE_ENVIRONMENT_API_KEY.
Start the server (stdio; typically launched by an MCP client, not used interactively):
npm startFor development with auto-reload:
npm run devAfter npm run build, add a server entry (adjust the path to your clone):
{
"mcpServers": {
"google-environment": {
"command": "node",
"args": ["/absolute/path/to/environment-mcp/dist/index.js"],
"env": {
"GOOGLE_MAPS_API_KEY": "your-key-here"
}
}
}
}You can omit env if GOOGLE_MAPS_API_KEY is already set in your shell profile and Cursor inherits it (behavior depends on how Cursor is launched).
Tool | API |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Air quality tools accept a JSON body with required location: { latitude, longitude } and optional fields per Google’s REST reference; other tools use typed arguments (coordinates, days, hours, unitsSystem, etc.).
Uses Ultracite (Biome preset):
npm run lint
npm run formatNever pass the API key in tool arguments; only use environment variables.
Restrict the key in Google Cloud Console (HTTP referrers for browser use; IP or server-only patterns for backend).
Google Air Quality API: current conditions at a location (hourly indexes, optional pollutants via extraComputations). POST body matches https://developers.google.com/maps/documentation/air-quality/reference/rest/v1/currentConditions/lookup — requires location with latitude and longitude; other optional fields are forwarded.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses that the POST body matches a specific API reference and that optional fields are forwarded, but it doesn't explain the response format, error behavior, or any side effects. This is partial disclosure for a read-only query 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 two sentences, front-loaded with purpose and immediately followed by the external API reference. It is concise, informative, and avoids redundancy with the schema.
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?
Given low schema coverage, no annotations, and no output schema, the description provides the essential required parameter and points to external documentation, but it omits a full list of optional parameters and details about the return structure. The external link helps, but the description alone is not fully self-contained for an agent to use correctly without additional research.
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 has no parameter descriptions, and the description compensates by clarifying that `location` must contain latitude and longitude. It also mentions `extraComputations` as an example of an optional field and provides an external API reference, but it does not enumerate all acceptable optional fields, leaving some ambiguity.
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 clearly identifies the tool as retrieving current air quality conditions at a location, specifying 'hourly indexes' and 'optional pollutants via extraComputations'. This distinguishes it from sibling tools like air_quality_forecast and air_quality_history, and the reference to the specific API endpoint adds precision.
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 states that a `location` with latitude and longitude is required, which is a clear usage prerequisite. It implies the tool is for current conditions, naturally distinguishing it from forecast/history tools, but it does not explicitly mention when to prefer this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Air Quality API: hourly forecast for a time range or specific hour. POST body matches https://developers.google.com/maps/documentation/air-quality/reference/rest/v1/forecast/lookup — requires location; use period (startTime/endTime), dateTime, or hours per API docs.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes |
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 adds useful context by indicating this is a POST request and linking to the official Google Air Quality API reference, which goes beyond the schema. However, it does not mention response format, authentication, rate limits, or side effects, leaving notable gaps.
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 one efficient sentence that leads with the core purpose and packs in the POST body reference, required parameter, and time-range options without filler. The long URL is justified as the authoritative API documentation link.
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?
Since there is no output schema and no annotations, the description should ideally explain return values and operational behavior. It gives enough to construct a request via the external docs and time selections, but it omits response structure, authentication needs, and error handling, making it only partially complete.
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 `location` with lat/long constraints but has no property descriptions (0% coverage). The description compensates by requiring `location` and naming the additional body fields (`period`, `dateTime`, `hours`) not present in the schema, which is essential because `additionalProperties: true` allows these fields.
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 clearly identifies the tool as an hourly air quality forecast for a time range or specific hour. It names the exact resource and verb, and the temporal scope distinguishes it from sibling tools like air_quality_current_conditions and air_quality_history.
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 states that `location` is required and explains the three time-selection options (`period`, `dateTime`, `hours`), giving clear guidance on how to adjust the forecast window. However, it does not explicitly state when to prefer this over the current-conditions or history alternatives, nor does it list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Air Quality API: historical hourly data. POST body matches https://developers.google.com/maps/documentation/air-quality/reference/rest/v1/history/lookup — requires location; use period, dateTime, or hours (1–720) per API docs.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that this is a POST lookup against a Google API and constrains `hours` to 1–720, but it does not mention authentication, rate limits, or response/error behavior, leaving important operational details implicit.
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 a single dense sentence with no filler; it front-loads the purpose and packs in the endpoint, required parameter, and time-parameter options/range efficiently.
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?
For a tool with no output schema and an open additional-properties schema, the description gives enough to construct a basic request (endpoint, required param, time-filter options). Yet it omits response shape, pagination, units, and exact formats for `dateTime`/`period`, relying on the linked API docs, so completeness is adequate but not thorough.
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 `location` with `additionalProperties: true`, so the description adds critical semantics by naming the required `location` and optional time parameters (`period`, `dateTime`, `hours`) and the valid hours range. It compensates for the low schema coverage, though it does not specify formats for all params.
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 clearly identifies the tool as Google Air Quality API historical hourly data and names the exact history lookup endpoint, which distinguishes it from current conditions and forecast siblings. However, it lacks an explicit action verb (e.g., 'retrieves'), so it falls short of the top tier for verb+resource phrasing.
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 gives clear invocation context: it requires `location` and directs the agent to use `period`, `dateTime`, or `hours` (1–720) as time filters. It does not explicitly name sibling tools as alternatives, but 'historical hourly data' makes the appropriate use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Pollen API: daily pollen forecast (1–5 days) at a location. See https://developers.google.com/maps/documentation/pollen/forecast
| Name | Required | Description | Default |
|---|---|---|---|
| days | Yes | ||
| latitude | Yes | ||
| longitude | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It only states 'daily pollen forecast' and a link, but does not describe the response format, pollen types, units, or any access requirements. The link may cover details, but the description itself is minimal.
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 a single concise sentence with an additional reference link. It is front-loaded with the most important information and contains no 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?
Given the simple numeric parameters and lack of output schema, the description is minimally complete: it explains the input scope (location, days) and the domain (pollen). However, it does not describe what the response contains, such as pollen types or severity indices, leaving some gaps.
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 has 0% description coverage, so the description must compensate. It mentions 'at a location' (latitude/longitude) and '1–5 days' (days), which adds meaning, but it does not explain parameter names, formats, or constraints beyond what the schema already shows. This is adequate but not thorough.
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 clearly states the tool provides a daily pollen forecast for 1–5 days at a location, which distinguishes it from sibling tools for air quality and weather. The verb 'forecast' and resource 'pollen' make the purpose specific and unambiguous.
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 use for pollen forecasting, which contrasts with the sibling tools for air quality and weather. It does not explicitly state when not to use it or name alternatives, but the domain is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Weather API: current conditions at a location. See https://developers.google.com/maps/documentation/weather/current-conditions
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | ||
| longitude | Yes | ||
| unitsSystem | No | ||
| languageCode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden for behavioral disclosure. It names the API provider and gives a documentation URL, but does not disclose return format, units handling, rate limits, or whether the operation is read-only. This is minimal behavioral context beyond purpose.
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 very concise and front-loaded, containing just the core purpose and a documentation link. It does not waste words, though it could be considered slightly under-specified for the tool's parameter and return complexity.
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?
With no output schema and no annotations, the description should compensate by explaining what current conditions are returned (temperature, humidity, wind, etc.) and any caveats. It does not, leaving the agent with only a vague promise of 'current conditions' and an external URL.
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?
Schema description coverage is 0%, and the description does not explain any parameters. 'At a location' vaguely implies latitude/longitude, but unitsSystem and languageCode are unaddressed, forcing the agent to rely only on the schema's names and enum values.
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 clearly states the tool returns 'current conditions at a location,' which is a specific resource and scope. It distinguishes from sibling forecast/history/air-quality tools by the word 'current,' though it lacks an explicit verb like 'get' or 'retrieve.'
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 implies use when current weather conditions are needed, and the sibling names help clarify alternatives. However, it does not explicitly state when to use this tool versus weather_forecast_days, weather_history_hours, or other weather-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Weather API: up to 10 days of daily forecast. See https://developers.google.com/maps/documentation/weather/daily-forecast
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| latitude | Yes | ||
| pageSize | No | ||
| longitude | Yes | ||
| pageToken | No | ||
| unitsSystem | No | ||
| languageCode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It does disclose a key behavioral trait: a limit of 'up to 10 days' and the daily nature of the forecast. However, it omits other behaviors like default units, pagination behavior, error handling, or authentication requirements. The external link may offer more details, but the description itself is sparse.
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 highly concise: a single front-loaded sentence stating the core purpose and a link to official documentation. There is zero fluff or redundant content. Every word adds value, and the structure is optimal for quick scanning.
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?
Given the tool's complexity (7 parameters, no output schema) and missing usage guidance, the description is incomplete. It provides a basic purpose but fails to contextualize parameters, clarify when to use it, or describe the return format. The external link might help, but the description should be self-sufficient for an AI agent to invoke the tool correctly.
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?
Schema description coverage is 0%, so the description must compensate. It only adds meaning for the 'days' parameter by mentioning the 10-day limit. Parameters like pageSize, pageToken, unitsSystem, and languageCode are left unexplained. While the names are somewhat self-explanatory, the description does not clarify defaults or usage semantics, leaving a significant gap.
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 clearly states the tool provides 'up to 10 days of daily forecast,' identifying both the verb (provide/return) and resource (daily forecast). It distinguishes from siblings like weather_forecast_hours and weather_current_conditions by specifying daily granularity. A minor lack of an explicit verb like 'retrieve' prevents a perfect score.
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?
No guidance is given on when to use this tool versus alternatives such as weather_forecast_hours or weather_history_hours. The description does not mention any exclusions, prerequisites, or preferred scenarios. The only implicit hint is the tool's name and the phrase 'daily forecast,' but explicit usage direction is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Weather API: up to 240 hours of hourly forecast. See https://developers.google.com/maps/documentation/weather/hourly-forecast
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| latitude | Yes | ||
| pageSize | No | ||
| longitude | Yes | ||
| pageToken | No | ||
| unitsSystem | No | ||
| languageCode | No |
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 only repeats the schema limit of 240 hours and fails to mention pagination (pageToken/pageSize), units, or other operational behaviors, offering minimal transparency.
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 a single concise sentence plus a documentation link. It is appropriately sized and front-loaded, though the link could be considered supplementary rather than essential.
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?
For a tool with 7 parameters, no annotations, and no output schema, the description is too sparse. It omits details on pagination, units, language, and response structure, making it inadequate for effective use in complex scenarios.
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?
Schema description coverage is 0%, and the description only adds value for the 'hours' parameter via the 240-hour limit. It does not explain unitsSystem, languageCode, pageToken, or pageSize, leaving most parameters semantically unexplained.
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 clearly states the tool provides 'up to 240 hours of hourly forecast', identifying the resource and scope. Although it lacks an explicit verb like 'get' or 'retrieve', it distinguishes from sibling tools like weather_forecast_days and weather_current_conditions by specifying 'hours'.
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?
No guidance is given on when to use this tool versus alternatives like weather_forecast_days or weather_history_hours. The description only mentions the Google Weather API and the hour range, with no explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Weather API: up to 24 hours of historical hourly weather. See https://developers.google.com/maps/documentation/weather/hourly-history
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| latitude | Yes | ||
| pageSize | No | ||
| longitude | Yes | ||
| pageToken | No | ||
| unitsSystem | No | ||
| languageCode | No |
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 does mention the 'up to 24 hours' limitation, which is useful, but it fails to disclose pagination behavior, response format, required authentication, or any other operational constraints. The API link is a pointer, not a substitute for inline transparency.
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 a single sentence with a documentation link, making it concise and front-loaded. There is no redundant filler, though the link is not described in text. It is efficient but slightly too sparse to carry the necessary information.
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?
Given the tool has seven parameters, no output schema, and no annotations, the description is not complete enough for an agent to use confidently. It provides a broad summary and a link, but leaves out essential operational details like required parameters, pagination, and return value structure.
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?
Schema description coverage is 0%, and the description does not explain any of the seven parameters beyond implying that 'hours' is capped at 24. It does not mention latitude/longitude, pageToken, unitsSystem, or languageCode, so an agent cannot determine how to fill these parameters from the description alone.
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 clearly identifies the resource as historical hourly weather data limited to 24 hours, which distinguishes it from sibling tools like weather_forecast_hours and weather_current_conditions. However, it lacks an explicit verb such as 'retrieve' or 'get', making it slightly less direct.
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 term 'historical' implicitly signals this is for past weather data rather than forecasts or current conditions, but there is no explicit guidance about when to choose this tool over alternatives or any exclusions. The sibling tool names help, but the description itself does not provide concrete usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Weather API: public weather alerts intersecting a location. See https://developers.google.com/maps/documentation/weather/weather-alerts
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | ||
| pageSize | No | ||
| longitude | Yes | ||
| pageToken | No | ||
| languageCode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'public weather alerts intersecting a location' and provides a link, but it does not mention pagination behavior, response format, or any operational characteristics like rate limits or data freshness.
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 a single sentence with no redundancy, plus a documentation link. It is front-loaded and efficient, with every word contributing to the core message.
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?
The tool has 5 parameters, no output schema, and no annotations, yet the description does not explain return values, pagination mechanics, or language handling. The external link may help, but the description itself is not self-sufficient for an agent to use the tool correctly without additional lookups.
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?
Schema description coverage is 0%, so the description must compensate. It only hints that 'intersecting a location' relates to latitude/longitude, but says nothing about pageSize, pageToken, or languageCode semantics. The property names are self-explanatory, but the description adds minimal value beyond the schema.
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 clearly states the tool returns public weather alerts intersecting a location, which distinguishes it from sibling tools like current conditions or forecasts. The verb is implied rather than explicit ('public weather alerts intersecting a location' does not literally say 'retrieve'), but the resource and scope are clear.
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?
No guidance is given on when to use this tool versus weather_forecast_days, weather_current_conditions, or other siblings. There are no exclusions, prerequisites, or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0air_quality_current_conditionsair_quality_forecastair_quality_historypollen_forecastweather_current_conditionsweather_forecast_daysweather_forecast_hoursweather_history_hoursweather_public_alertsScored across 9 tools
Each tool targets a unique combination of environmental domain (air quality, pollen, weather) and time dimension (current, forecast, history, alerts), making them clearly distinct. Even within the same domain, tools like weather_forecast_days and weather_forecast_hours are differentiated by granularity.
All tool names follow a consistent lowercase_with_underscores pattern: domain_first (air_quality, pollen, weather) followed by a type modifier (current_conditions, forecast, history, alerts). There is no mixing of camelCase or other conventions.
Nine tools is a well-scoped count for an environment API server covering three sub-domains. Each tool maps to a distinct Google API endpoint, and none are redundant or trivial, so the size feels appropriate.
The surface covers the full lifecycle of environmental data access for the included domains: current, forecast, and history for air quality; forecast for pollen; and current, forecast, history, and alerts for weather. No obvious dead ends or missing operations within the stated scope.
The official Model Context Protocol server for Ambee. It gives any MCP-compatible AI assistant — Claude, ChatGPT, Cursor, VS Code, Ollama, and more direct access to live air quality, pollen, and weather data. To get started, including information on signing up and obtaining your Ambee key, check out the Ambee documentation on https://docs.ambeedata.com
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
Air Quality MCP — wraps air-quality-api.open-meteo.com (free, no auth)
MCP server for weather with reasoning — umbrella advice, outdoor checks, city comparisons.
