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
Get an hourly air quality and pollutant forecast for the next 48 hours for a location.
You must provide EITHER:
lat and lng (if you already have or confidently know the coordinates), OR
place (a free-text place name, e.g. "Bengaluru", "Baker Street, London", "90210, US") — the API resolves this to a location itself, so do not try to geocode it yourself first, and do not call any other tool before this one.
Do not pass both lat/lng and place at once — pick one form.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the location (omit if using `place`). | |
| lng | No | Longitude of the location (omit if using `place`). | |
| place | No | Free-text place name like a city, street, or postcode with country (omit if using `lat`/`lng`). | |
| locale | No | Optional. If set, adds local time to each hourly record. | |
| aqiStandard | No | Optional. The standard used to calculate the Air Quality Index. You can pass any of these five: EPA, IN, UK, CN, CA. And default value is EPA. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It discloses that the API itself resolves free-text place names and that no preceding geocoding tool call is needed. It could add more about units or error behavior, but the key behaviors for a read-only forecast are well covered.
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?
Front-loaded with a one-sentence purpose, followed by a clear bullet-style breakdown of input constraints. The repetition of 'do not pass both' and 'pick one form' is slightly redundant but reinforces the most important usage rule.
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?
Combined with 100% schema coverage and an output schema, the description provides everything needed to invoke the tool correctly: location alternatives, geocoding behavior, and forecast horizon. No critical gap remains for an agent to call it safely and 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 coverage is 100%, so the schema already documents all five parameters. The description adds real value by defining the mutually exclusive lat/lng vs place relationship, providing concrete place examples, and warning against passing both forms at once.
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?
States a specific verb ('Get'), an exact resource ('hourly air quality and pollutant forecast'), and scope ('next 48 hours for a location'). This clearly differentiates it from siblings like air_quality_latest and pollen_forecast by resource and forecast horizon.
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?
Provides explicit rules for input selection: use either lat/lng or place, never both, and do not geocode first or call other tools beforehand. It does not explicitly name air_quality_latest as the current-conditions alternative, but the forecast-vs-latest distinction is clear from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the real-time, latest air quality reading and individual pollutant concentrations for a location.
You must provide EITHER:
lat and lng (if you already have or confidently know the coordinates), OR
place (a free-text place name, e.g. "Bengaluru", "Baker Street, London", "90210, US") — the API resolves this to a location itself, so do not try to geocode it yourself first, and do not call any other tool before this one.
Do not pass both lat/lng and place at once — pick one form.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the location (omit if using `place`). | |
| lng | No | Longitude of the location (omit if using `place`). | |
| place | No | Free-text place name like a city, street, or postcode with country (omit if using `lat`/`lng`). | |
| locale | No | Optional. If set, adds local time to the record. | |
| aqiStandard | No | Optional. The standard used to calculate the Air Quality Index. You can pass any of these five: EPA, IN, UK, CN, CA. And default value is EPA. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that the API resolves free-text place names itself, that the agent should not attempt geocoding, and that lat/lng and place must not both be passed. This goes well beyond the schema. It stops short of describing failure behavior or limits, but the core behavioral traits are covered.
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 well-structured and front-loaded: purpose first, then parameter rules in a clear either/or layout. Every sentence earns its place, including the practical warning not to geocode or call other tools.
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 five optional parameters, the mutually exclusive input modes, and the presence of an output schema, the description is complete enough. It explains what the tool returns, how to specify the location, which parameters are optional, and the key behavioral constraints an agent needs to invoke it 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 coverage is 100%, so the baseline is 3. The description adds real value by explaining the decision between coordinate forms ('if you already have or confidently know the coordinates'), clarifying that the API resolves place names itself, and warning against passing both forms. This goes beyond the schema's brief 'omit if using' notes.
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 opens with a clear verb and resource: 'Get the real-time, latest air quality reading and individual pollutant concentrations for a location.' This distinguishes it from siblings like air_quality_forecast, pollen_latest, and weather_latest by explicitly scoping it to current air quality data.
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 makes the intended usage context clear: it is for latest air quality at a location, with explicit either/or instructions for lat/lng versus place. It also tells the agent not to geocode or call other tools first. However, it does not explicitly name alternatives or state when to prefer a forecast or pollen tool over this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an hourly pollen count and risk forecast for the next 48 hours for a location.
You must provide EITHER:
lat and lng (if you already have or confidently know the coordinates), OR
place (a free-text place name, e.g. "Bengaluru", "Baker Street, London", "90210, US") — the API resolves this to a location itself, so do not try to geocode it yourself first, and do not call any other tool before this one.
Do not pass both lat/lng and place at once — pick one form.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the location (omit if using `place`). | |
| lng | No | Longitude of the location (omit if using `place`). | |
| place | No | Free-text place name like a city, street, or postcode with country (omit if using `lat`/`lng`). | |
| locale | No | Optional. If set, adds local time to each hourly record. | |
| species_risk | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 reveals a non-obvious behavior: the API performs geocoding internally, so the agent should not pre-geocode or call other tools first. This goes beyond the basic 'Get' purpose and adds meaningful process transparency, though it does not elaborate on response shape or error cases (partly mitigated by the output schema).
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 well-structured and front-loaded with the core purpose. The bullet-like location alternatives are easy to parse, examples clarify the free-text format, and every sentence carries necessary constraints. No filler or redundancy.
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 the core task of retrieving a 48-hour pollen forecast, the description is complete: it specifies the temporal range, the location options, and the constraint against pre-geocoding. The output schema covers return values. The main gap is that the optional locale and species_risk parameters are not explained in the description, and species_risk has no schema description either, leaving an agent to guess its meaning.
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 description adds valuable semantics beyond the schema by defining the relationship between lat/lng and place, including when to choose each and the mutual-exclusion rule. Schema coverage is 80% but not above that threshold, and the remaining species_risk parameter is left entirely undocumented in both the schema and description, so the description does not fully compensate.
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 opens with a specific verb ('Get'), a clear resource ('hourly pollen count and risk forecast'), and a precise temporal scope ('next 48 hours'). This clearly distinguishes it from the sibling pollen_latest, which presumably returns current conditions, and from air_quality/weather tools.
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 explicit guidance on how to provide the location: either lat/lng or place, with the instruction to pick one form and not pass both. It also tells the agent not to geocode itself or call another tool first, which is useful workflow context. However, it does not explicitly contrast with pollen_latest or other alternatives, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the real-time, latest pollen count and risk levels for tree, weed, and grass pollen for a location.
You must provide EITHER:
lat and lng (if you already have or confidently know the coordinates), OR
place (a free-text place name, e.g. "Bengaluru", "Baker Street, London", "90210, US") — the API resolves this to a location itself, so do not try to geocode it yourself first, and do not call any other tool before this one.
Do not pass both lat/lng and place at once — pick one form.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the location (omit if using `place`). | |
| lng | No | Longitude of the location (omit if using `place`). | |
| place | No | Free-text place name like a city, street, or postcode with country (omit if using `lat`/`lng`). | |
| locale | No | Optional. If set, adds local time to the record. | |
| species_risk | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that the API resolves place names itself, warns against geocoding, and enforces a call-order constraint. It does not discuss failure modes or ambiguous places, but it covers the most important behavioral traits.
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 well-structured: purpose first, then location requirements, then the exclusions. Every sentence provides actionable guidance, and the line breaks make the either/or constraint easy to parse.
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 an output schema, the description sufficiently explains how to select and pass location. The only notable gap is the undocumented species_risk parameter, which the agent would have to infer from the name. Overall, the essential calling context is present.
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 coverage is 80%, and the description adds meaningful disambiguation beyond the schema: the either/or relationship between lat/lng and place, and the instruction not to pass both. The species_risk parameter has no schema description and is not clarified in the tool description, which is a minor 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 opens with a specific verb and resource: 'Get the real-time, latest pollen count and risk levels for tree, weed, and grass pollen for a location.' This clearly distinguishes the tool from its pollen_forecast sibling by emphasizing it returns current/latest data rather than a forecast.
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 explicit location-parameter prerequisites: either lat/lng or a free-text place, not both, and instructs not to geocode or call another tool first. It does not explicitly contrast with pollen_forecast or weather/air-quality siblings, but the 'real-time, latest' framing makes the primary use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an hourly weather forecast for the next 48 hours for a location.
You must provide EITHER:
lat and lng (if you already have or confidently know the coordinates), OR
place (a free-text place name, e.g. "Bengaluru", "New York") — the API resolves this to a location itself, so do not try to geocode it yourself first, and do not call any other tool before this one.
Do not pass both lat/lng and place at once — pick one form.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the location (omit if using `place`). | |
| lng | No | Longitude of the location (omit if using `place`). | |
| place | No | Free-text place name like a city, street, or postcode with country (omit if using `lat`/`lng`). locale: Optional. If set, adds local time to each hourly record. | |
| units | No | Optional. you can pass any of these three imperial, metric, si. | |
| locale | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and it discloses useful behavioral traits: the API resolves place names itself, so the agent should not geocode beforehand, and the lat/lng vs place forms are mutually exclusive. It does not discuss rate limits, errors, or side effects, but for a read-only weather forecast with an output schema these omissions are minor.
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 front-loaded with the core purpose and then gives compact, clearly formatted input rules. The bullet list makes the mutually exclusive options easy to parse, and every sentence earns its place.
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 forecast tool with an output schema and no required parameters, the description covers the essential calling context: output granularity, input alternatives, and the no-geocoding rule. The only notable incompleteness is the absence of any explanation for the locale parameter, whose schema entry is also blank.
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 description adds real meaning beyond the schema for lat/lng/place by explaining the exclusive-or relationship and the API's place resolution behavior. Schema coverage is 80%, so the schema already handles most parameter meaning, but the locale parameter lacks a schema description and is not explained in the tool description, which is the main 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 opens with a specific verb and resource: 'Get an hourly weather forecast for the next 48 hours for a location.' The temporal scope (48-hour hourly forecast) and resource (weather forecast) distinguish it from siblings like weather_latest and the air_quality/pollen tools without needing to name them.
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?
Usage guidance is explicit for inputs: the agent must choose either lat/lng or place, must not pass both, and should not geocode or call another tool first when using place. It does not explicitly name sibling alternatives such as weather_latest, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the real-time, latest weather observation including temperature, humidity, wind, and UV index for a location.
You must provide EITHER:
lat and lng (if you already have or confidently know the coordinates), OR
place (a free-text place name, e.g. "Bengaluru", "Baker Street, London", "90210, US") — the API resolves this to a location itself, so do not try to geocode it yourself first, and do not call any other tool before this one.
Do not pass both lat/lng and place at once — pick one form.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the location (omit if using `place`). | |
| lng | No | Longitude of the location (omit if using `place`). | |
| place | No | Free-text place name like a city, street, or postcode with country (omit if using `lat`/`lng`). | |
| units | No | Optional. you can pass any of these three imperial, metric, si. And default value is imperial. | |
| locale | No | Optional. If set, adds local time to the record. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the API resolves free-text place names itself, warns against pre-geocoding, and says not to call another tool first. This is meaningful behavioral context beyond what the schema states.
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 well-structured and front-loaded: purpose first, then parameter usage rules, then an explicit exclusion. Every sentence earns its place, and the bullet-style layout is easy for an agent to parse.
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 output schema and the fully documented parameters, the description is complete enough for correct invocation. It covers what the tool returns, how to select a location form, and the key workflow trap to avoid. No critical calling information is missing.
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 coverage is 100%, so the baseline is 3. The description adds real value on top by explaining the mutually exclusive lat/lng vs place relationship, providing place-name examples, and giving a heuristic for when to use coordinates. It does not elaborate on units or locale, but the schema already covers those clearly.
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 opens with a specific verb and resource: 'Get the real-time, latest weather observation including temperature, humidity, wind, and UV index for a location.' It clearly differentiates from the forecast and air-quality/pollen siblings through the 'latest weather observation' framing and its listed fields.
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?
It gives explicit instruction on how to choose between lat/lng and place, including a concrete 'do not pass both' rule and examples. It does not explicitly name alternatives like weather_forecast or air_quality_latest, but the 'latest observation' wording carries much of that context.
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. Dates show when Glama detected each change.
air_quality_forecastair_quality_latestpollen_forecastpollen_latestweather_forecastweather_latestClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
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)
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Hosted MCP server for live public-data APIs and Skills for AI agents.
Add one secure layer between your agents and this server.
Each tool has a unique combination of domain (air quality, pollen, weather) and temporal scope (forecast, latest), making selection unambiguous. No two tools overlap in purpose.
All tool names follow a strict {domain}_{time_type} pattern, with every domain offering a _forecast and _latest variant. This creates a highly predictable and coherent naming scheme.
With exactly 6 tools covering three environmental domains and two temporal modes, the count is well-balanced and each tool earns its place. The set is neither bloated nor thin.
The server provides both real-time and forecast data for all three core domains it targets (air quality, pollen, weather), offering complete coverage for its apparent purpose. No obvious missing operations that would cause agent failures.
