aviation-weather-mcp-server
Server Details
Fetch METARs, TAFs, PIREPs, and SIGMETs/AIRMETs from the NWS Aviation Weather Center.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 5 of 5 tools scored.
Each tool retrieves a distinct type of aviation weather data: stations, advisories, METARs, PIREPs, and TAFs. Descriptions clearly explain when to use each, preventing any confusion.
All tools follow a consistent `aviation_<verb>_<noun>` pattern, with verbs mostly 'get' and 'find' appropriately used for the station search. Nouns are the specific data type, making the naming predictable and clear.
Five tools cover the essential aviation weather domain: station lookup, observations, forecasts, advisories, and pilot reports. The count is well-scoped without being excessive or too sparse.
The set covers primary weather products like METAR, TAF, SIGMET/AIRMET, and PIREPs, but lacks winds aloft data (FDs), which is a common aviation weather component. Still, the core surface is well-covered.
Available Tools
5 toolsaviation_find_stationsFind Aviation Weather StationsARead-onlyIdempotentInspect
Resolve an airport or weather reporting station by ICAO identifier, or discover stations within a bounding box or US state. Returns all identifier variants (ICAO/IATA/FAA), coordinates, elevation, and available data types (METAR, TAF, SYNOP, etc.). Station IDs must be 4-letter ICAO format (e.g., KSEA, KJFK). At least one of station_ids, bbox, or state is required.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | Geographic bounding box for spatial queries. | |
| state | No | Two-letter US state abbreviation (e.g., "WA") to list all stations in that state. | |
| station_ids | No | One or more 4-letter ICAO station IDs (e.g., KSEA, KJFK). The upstream API only accepts ICAO format — 3-letter IATA codes (e.g., SEA) will return no results. Use bbox or state to discover ICAO IDs by location. |
Output Schema
| Name | Required | Description |
|---|---|---|
| stations | Yes | Matching stations. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by detailing return values and input constraints. No contradictions, but could mention rate limits or pagination if applicable.
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?
Two sentences with no fluff. The first sentence defines the core functionality, the second explains constraints and alternatives. Perfectly front-loaded.
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?
Covers all three parameters, explains return values, and uses the output schema for further detail. No gaps given the tool's simplicity.
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%, but the description adds critical nuance: station_ids must be ICAO format (not IATA), and explains the purpose of bbox and state. This exceeds the schema's own descriptions.
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 resolves stations by ICAO identifier, bounding box, or US state, and lists the returned data types. This distinguishes it from sibling tools (advisories, METAR, etc.) which focus on weather data retrieval.
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?
Explicitly states that at least one of station_ids, bbox, or state is required, warns that IATA codes will fail, and suggests using bbox/state to discover ICAO IDs. Provides clear when-to-use and constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aviation_get_advisoriesGet Active Aviation Advisories (SIGMETs / AIRMETs)ARead-onlyIdempotentInspect
Get active SIGMETs and AIRMETs for a region. Returns each advisory with hazard type (CONVECTIVE, TURBULENCE, ICING, IFR, MTN OBSCN, etc.), severity, altitude range, valid period, polygon coordinates, and raw text. Coverage is US-centric (NWS Aviation Weather Center). During fair-weather periods no advisories may be active — an empty result is normal, not an error. Filter by advisory_type, hazard, or bbox.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | Geographic bounding box to filter advisories by polygon overlap. | |
| hazard | No | Optional hazard filter. CONVECTIVE = convective SIGMETs; TURBULENCE = AIRMET Tango; ICING = AIRMET Zulu; IFR = AIRMET Sierra (IFR conditions); MTN OBSCN = AIRMET Sierra (mountain obscuration); SURFACE WIND = sustained strong surface winds (typically >30 kt); LLWS = low-level wind shear below 2,000 ft AGL. | |
| advisory_type | No | Filter by advisory type. "sigmet" includes convective SIGMETs. "airmet" includes AIRMET Sierra (IFR/mountain obscuration), Tango (turbulence), and Zulu (icing). "all" returns both. | all |
Output Schema
| Name | Required | Description |
|---|---|---|
| advisories | Yes | Active advisories matching the filter criteria. May be empty during fair weather periods. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. The description adds context: US-centric (NWS Aviation Weather Center) and clarifies that empty results are not an error. No contradictions.
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 focused paragraph that front-loads the main purpose, lists key output fields, data source, and filtering options without unnecessary fluff.
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 3 optional parameters and an output schema, the description covers the returned data, filtering, data source, and edge case (empty result). It is complete for an agent to use.
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 describes all 3 parameters thoroughly (100% coverage) with type, enums, and descriptions. The description only summarizes filtering options, adding 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 gets active SIGMETs and AIRMETs for a region, listing returned fields and data source. It distinguishes from sibling tools (stations, METAR, PIREPs, TAF) by focusing on advisories.
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 explains when to use the tool (for active advisories in a region) and notes that empty results during fair weather are normal. It does not explicitly compare to alternatives but the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aviation_get_metarGet METAR Weather ObservationsARead-onlyIdempotentInspect
Get current weather observations (METARs) for one or more airports. Returns decoded fields — wind direction/speed/gusts, visibility, ceiling, temperature, dewpoint, altimeter, cloud layers — plus the computed flight category (VFR/MVFR/IFR/LIFR) and the raw METAR string. Accepts 1–10 ICAO station IDs (e.g., KSEA, KJFK). Use aviation_find_stations to resolve or verify an ICAO ID, or to discover nearby stations.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | Hours of observation history to return (1–12). Default 1 returns only the most recent observation per station. | |
| station_ids | Yes | ICAO station IDs to query. 1–10 stations per call. |
Output Schema
| Name | Required | Description |
|---|---|---|
| observations | Yes | Weather observations, one per station/time pair. Multiple entries per station when hours > 1. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare `readOnlyHint`, `openWorldHint`, and `idempotentHint`. The description adds behavioral details: returns decoded fields and computed flight category, and notes that default hours=1 returns only the most recent observation. No contradictions with annotations.
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 of about 50 words, efficiently covering purpose, output, input constraints, and a pointer to a sibling tool. It is front-loaded with the core purpose, though it could be slightly more structured with bullet points.
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 an output schema (not shown) and simple input schema with two parameters, the description adequately covers input constraints (1-10 IDs, hours range), output fields, and relationship to `aviation_find_stations`. No gaps identified.
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?
With 100% schema description coverage, the schema already documents both parameters. The description reinforces the 'hours' default behavior and the array length constraint, but adds minimal new semantic 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 retrieves current weather observations (METARs) for airports, lists output fields (wind, visibility, ceiling, etc.), and specifies it accepts 1-10 ICAO station IDs. This distinguishes it from siblings like `aviation_get_taf` (forecasts) and `aviation_find_stations` (station lookup).
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 explicitly recommends using `aviation_find_stations` to resolve or verify ICAO IDs, providing clear guidance for tool selection. It does not explicitly state when to avoid using this tool, but the association with sibling names implies alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aviation_get_pirepsGet Pilot Reports (PIREPs)ARead-onlyIdempotentInspect
Get recent Pilot Reports (PIREPs) near an airport or within a bounding box. Returns decoded turbulence, icing, and cloud reports with altitude, aircraft type, intensity, and the raw PIREP string. Requires either station_id (ICAO center point for radial search, e.g., KSEA) or bbox (area search) — not both. Coverage is US-centric; PIREPs are sparse and absence of reports does not imply smooth conditions.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | Geographic bounding box for area PIREP search. | |
| hours | No | How many hours of history to return. Default 3. | |
| station_id | No | ICAO station ID as center point for radial search (e.g., KSEA). Use with distance_nm. | |
| distance_nm | No | Search radius in nautical miles around station_id. Only used when station_id is provided. Default 100. | |
| altitude_max_ft | No | Filter by maximum altitude in feet MSL (e.g., 35000 for FL350). Optional. | |
| altitude_min_ft | No | Filter by minimum altitude in feet MSL (e.g., 18000 for FL180). Optional. |
Output Schema
| Name | Required | Description |
|---|---|---|
| pireps | Yes | Pilot reports matching the search criteria, ordered by observation time descending. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, idempotent. The description adds valuable behavioral context: mutual exclusivity of parameters, coverage limitations (US-centric, sparse), and the caveat about smooth conditions. No contradictions.
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?
Three sentences, each earning its place: first states main action, second lists outputs, third covers constraints and caveats. Front-loaded and no 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?
Given 6 parameters, nested objects, and existing output schema, the description fully covers purpose, return types, parameter constraints, and caveats. No gaps remain.
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 baseline is 3. The description adds critical mutual exclusivity rule (station_id vs bbox) and clarifies that distance_nm is used only with station_id, which is not fully captured in 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 retrieves recent PIREPs near an airport or bounding box, listing specific report types (turbulence, icing, cloud) with attributes. It distinguishes from sibling tools like METAR, TAF, advisories by specificity.
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 provides clear usage context: requires either station_id or bbox (not both), notes US-centric coverage and sparsity of PIREPs, and warns that absence does not imply smooth conditions. It does not explicitly compare to alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aviation_get_tafGet Terminal Aerodrome Forecast (TAF)ARead-onlyIdempotentInspect
Get the Terminal Aerodrome Forecast (TAF) for one or more airports. Returns each forecast period with valid times, wind, visibility, decoded weather conditions, and cloud layers, plus the raw TAF string. TAFs cover the next 24–30 hours and are issued only for airports with scheduled commercial service; check data_types from aviation_find_stations to confirm TAF availability. Accepts 1–4 ICAO station IDs (e.g., KSEA, KJFK).
| Name | Required | Description | Default |
|---|---|---|---|
| station_ids | Yes | ICAO station IDs to query. 1–4 stations per call. |
Output Schema
| Name | Required | Description |
|---|---|---|
| forecasts | Yes | TAF forecasts, one per requested station. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds context about the output structure (forecast periods, wind, visibility, weather conditions, cloud layers, raw TAF string) and constraints (only for airports with scheduled commercial service). This provides behavioral context beyond the annotations.
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 concise at three sentences, front-loaded with the purpose, and every sentence provides necessary information. No redundancy or fluff.
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 presence of an output schema, the description appropriately summarizes the return values without duplicating the schema. It covers time coverage, availability constraints, and the use of aviation_find_stations for verification, making the tool self-contained enough for an agent to decide when to use it.
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 input schema has 100% description coverage for the only parameter (station_ids). The description reinforces the ICAO format with examples (KSEA, KJFK) and clarifies the allowed range (1-4 stations). This adds value beyond the schema 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 states the action ('Get') and resource ('Terminal Aerodrome Forecast (TAF) for one or more airports'). It distinguishes from sibling tools by specifying the data type (TAF vs. METAR, advisories, etc.) and mentions the station ID format and count.
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 explains when to use this tool (for TAF forecasts) and includes a clear guideline to check TAF availability via aviation_find_stations. It also specifies the valid number of station IDs (1-4) and the coverage period (24-30 hours). However, it does not explicitly mention when not to use it or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
Discussions
No comments yet. Be the first to start the discussion!