faa-traffic-delays-mcp-server

List Active FAA Delay Events

faa_delays_list_active_events

Read-onlyIdempotent

List every active FAA traffic management event across the National Airspace System in one call: ground stops, Ground Delay Programs, Airspace Flow Programs, arrival and departure delays, airport closures, closure NOTAMs, and deicing. Rows are sorted by severity (airport closures in effect, ground stops, then GDPs and then AFPs each by average delay, arrival/departure delays by band maximum, closure NOTAMs and airport closures outside their daily window, deicing) and carry the reason, delay figures, times, and an advisory reference for faa_delays_get_advisory. Use faa_delays_get_airport_status for the full detail of one airport, including its GDP delay profile and runway configuration.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "faa_delays_list_active_events"
  }
}

Input Schema

Name	Required	Description	Default
`event_types`	No	Only these event types: ground_stop, ground_delay_program, airspace_flow_program, arrival_delay, departure_delay, airport_closure, closure_notam, deicing. Also accepts gs, gdp, afp, spelled-out names such as "departure delay", and a comma-separated string; case-insensitive. Omit for every type. countsByType always covers the whole feed.

Output Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`shown`	No	Events returned after the event_types filter.
`events`	No	Active events matching event_types, sorted by severity.
`notice`	No	Guidance on empty or partial results, stale delay entries, and how to get the missing data.
`fetchedAt`	No	When this server fetched the airport events from the FAA (UTC ISO); with the 60 s cache it can trail the call by up to a minute.
`enRouteFeed`	No	Whether Airspace Flow Programs were read: ok, unavailable (the en-route feed failed), or format_changed (it returned a format this server does not read).
`totalActive`	No	Every active event read, before the event_types filter; excludes AFPs when the en-route feed could not be read.
`countsByType`	No	Active events per type across the whole feed, counted before the event_types filter so types the filter excluded stay visible. airspace_flow_program is absent when the en-route feed could not be read.
`appliedEventTypes`	No	The event_types filter as the server normalized it, or every type when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 4, 2026

changedOutput schema / properties / countsByType / properties / airport_closure / description

Previous value: -"Airport closures."New value: +"Airport closures, including any outside its daily window (inEffect false)."

changedOutput schema / properties / events / items / properties / closureText / description

Previous value: -"airport_closure exceptions, or the closure_notam NOTAM text (FAA-authored)."New value: +"The NOTAM text of an airport_closure or closure_notam row, or its wording without the NOTAM header when the FAA sends no NOTAM text (FAA-authored)."

addedOutput schema / properties / events / items / properties / dailyWindowUtc

Added value: +{
+  "additionalProperties": false,
+  "description": "The daily window the NOTAM schedules (a DLY HHMM-HHMM closing its text, with startTime on the first window start and endTime on the last window end): the closure applies only inside it, every day from startTime to endTime. Absent when the text states no such schedule.",
+  "properties": {
+    "end": {
+      "description": "Window end, HHMM UTC; earlier than start when the window crosses 0000Z.",
+      "type": "string"
+    },
+    "start": {
+      "description": "Window start, HHMM UTC.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "start",
+    "end"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / events / items / properties / inEffect

Added value: +{
+  "description": "Whether the closure applies at fetchedAt: between startTime and endTime and inside dailyWindowUtc. Present only with dailyWindowUtc; when false, the notice names the next window.",
+  "type": "boolean"
+}

First observedOct 2, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered; the description adds genuinely new behavior by disclosing the severity sort order and the fields each row carries (reason, delay figures, times, advisory reference). It does not discuss data freshness or how often "active" is refreshed, which is the one meaningful gap for a live-status feed.

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?

Two sentences, front-loaded with scope and followed by sorting and sibling routing. The severity-sort parenthetical is long but every clause names a distinct ranking tier, so it earns its length; the enumeration of event types overlaps somewhat with the schema enum.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return values, and the one optional parameter is fully covered by the schema. Scope, ordering, row contents, and sibling routing are all present, leaving nothing an agent needs in order to call this correctly.

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% and the single optional event_types parameter is fully documented there, including aliases, comma-separated form, case-insensitivity, and the countsByType caveat. The description adds nothing about the parameter, so the baseline of 3 applies.

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?

Opens with a specific verb and resource ("List every active FAA traffic management event across the National Airspace System") and immediately enumerates the eight event categories covered. It also names the sibling that handles the single-airport case, so the agent can distinguish this from faa_delays_get_airport_status without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: use this tool for the whole-system sweep, use faa_delays_get_airport_status for one airport's full detail (GDP profile, runway configuration), and use the advisory reference for faa_delays_get_advisory. The condition that selects each alternative is stated, not implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All faa-traffic-delays-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.