Skip to main content
Glama

faa-traffic-delays-mcp-server

List ATCSCC Advisories

faa_delays_list_advisories
Read-onlyIdempotent

List the ATCSCC advisories issued on one UTC date, newest first, from the FAA advisories database's per-date index: ground stops and delay programs as issued, proposed, revised, and canceled, required reroutes, flow constrained areas, operations plans, and CDM compression advisories, including those no longer active and those on past dates, which the NAS Status feed does not carry. Each row gives the advisory number, control element, subject, any further title lines (a reroute's name, constrained area, and valid period), and send time; its number and date open the full text with faa_delays_get_advisory. Narrow by categories or by control_element (an airport, its ICAO code, an ARTCC, or DCC for national advisories), and page with limit and offset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoUTC date to list, YYYY-MM-DD; MM/DD/YYYY and M/D/YYYY are also accepted. Omit for today (UTC). No later than tomorrow (UTC); past dates remain available.
limitNoAdvisories per page, 1–200.
offsetNoMatching advisories to skip, for paging: nextOffset from the previous page.
categoriesNoOnly advisories the FAA files under these categories: ground_stop, ground_delay_program, airspace_flow_program, ctop, route, other (flow constrained areas and operations plans file under other). Also accepts gs, gdp, afp, spelled-out names such as "ground stop", and a comma-separated string; case-insensitive. Omit for every advisory, including CDM compression advisories, which the FAA files under no category.
control_elementNoOnly advisories whose control element is this facility or lists it as a part: an airport by FAA identifier (ORD) or ICAO code (KORD), an ARTCC (ZAU), a pair (ORD/ZAU or KORD/ZAU), or DCC for national advisories such as reroutes and the operations plan. Case-insensitive. Airports named only in a subject or details do not match.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe limit applied; present only when more advisories remain.
dateNoThe UTC date read, YYYY-MM-DD; today (UTC) when date was omitted.
errorNoPresent when the call failed. Absent on success.
shownNoAdvisories on this page; present only when more remain.
noticeNoGuidance on an empty date, a filter that matched nothing, an offset past the end, more pages, and index rows that could not be read.
truncatedNoTrue when matching advisories remain past this page; absent otherwise.
advisoriesNoAdvisories issued on date that match categories and control_element, newest first: up to limit of them, starting at offset.
nextOffsetNooffset of the next page; present while matching advisories remain past this one.
totalCountNoAdvisories on date that match categories and control_element, before paging.
appliedCategoriesNoThe categories filter as the server normalized it; absent when omitted, which reads every advisory, uncategorized ones included.
appliedControlElementNoThe control_element filter as the server matched it: uppercased, each ICAO airport code in it mapped to its FAA identifier (KORD → ORD, KORD/ZAU → ORD/ZAU); absent when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent/open-world profile, and the description adds behavior the annotations cannot: newest-first ordering, inclusion of canceled and past-date advisories, default-to-today, and the quirk that CDM compression advisories are filed under no category. That is substantive operational context beyond the structured hints.

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 dense sentences, front-loaded with the action and ordering before enumerating categories and paging. Long, but nearly every clause carries distinct information; slight overloading of the first sentence costs it the top score.

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?

An output schema exists so return structure need not be re-explained, yet the description still summarizes row fields (advisory number, control element, subject, title lines, send time), and it covers filtering, paging, and follow-up routing. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds real semantics: categories omission includes uncategorized CDM compression advisories, and control_element only matches the indexed element (airports named solely in subject/details do not match). These parsing nuances beat the raw schema text.

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+resource+scope ('List the ATCSCC advisories issued on one UTC date, newest first') and enumerates the advisory families covered (ground stops, reroutes, FCAs, ops plans, CDM compression). It explicitly separates itself from the NAS Status feed and from sibling tools, so an agent can distinguish it without opening a 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?

States when to reach for this tool (historical/inactive advisories that the NAS Status feed lacks), how to narrow (categories, control_element, limit/offset paging), and routes to the sibling faa_delays_get_advisory for the full text. The condition that selects the alternative is spelled out rather than implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.