Skip to main content
Glama

faa-traffic-delays-mcp-server

Get ATCSCC Advisory

faa_delays_get_advisory
Read-onlyIdempotent

Get the full text of one ATCSCC advisory by its number and UTC date. faa_delays_list_advisories lists the advisories issued on a date with their numbers, and the advisory reference that faa_delays_list_active_events and faa_delays_get_airport_status return on program rows and faa_delays_get_operations_plan returns for the plan names one directly. Advisory text carries what the status feed omits: program rate by hour, delay assignment mode, scope, comments, and the operations plan's active constraints and runway closures. Advisory numbers restart at 1 each UTC day, and older advisories remain available.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "advisory_number": "<advisory_number>",
      "date": "<date>"
    },
    "name": "faa_delays_get_advisory"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateYesUTC date the advisory was issued, YYYY-MM-DD: date from the same faa_delays_list_advisories row or advisory reference. MM/DD/YYYY, as advisory titles print it, and M/D/YYYY are also accepted.
advisory_numberYesATCSCC advisory number, 1–999: number from a faa_delays_list_advisories row, or advisory.number from an advisory reference on faa_delays_list_active_events, faa_delays_get_airport_status, or faa_delays_get_operations_plan. The printed forms "ADVZY 082" and "082" are also accepted.

Output Schema

NameRequiredDescriptionDefault
capNoThe character ceiling applied; present only when the text was cut.
urlNoServer-built advisory URL this tool read; it also opens in a browser.
dateNoThe advisory UTC date read, YYYY-MM-DD.
textNoFull advisory text (FAA-authored), cut at 50,000 characters when longer; truncated then reports the cut.
errorNoPresent when the call failed. Absent on success.
foundNoWhether the FAA advisories database holds this advisory number on this UTC date.
shownNoCharacters of advisory text returned; present only when the text was cut.
titleNoAdvisory title line as the FAA prints it (FAA-authored), e.g. ATCSCC ADVZY 082 DCC 09/29/2026 OPERATIONS PLAN.
noticeNoGuidance on a cut advisory text; present only when the text was cut.
sentAtNoWhen the advisory was signed, ISO 8601 UTC, as faa_delays_list_advisories gives its send time. Absent when the page prints no signature or it names no real minute.
subjectNoAdvisory subject parsed from the title (CDM GROUND DELAY PROGRAM, OPERATIONS PLAN); absent when the title has another form.
guidanceNoPresent when found is false: where to get a valid advisory number and date.
truncatedNoTrue when the advisory text was cut at the 50,000-character ceiling; absent otherwise.
totalCharsNoFull length of the advisory text in characters; present only when the text was cut.
effectiveEndNoEnd of the effective period, ISO 8601 UTC: the first date at or after effectiveStart with the printed end day of month, in its month or the next. Present with effectiveStart.
effectiveTimeNoEffective period as the FAA prints it, DDHHMM-DDHHMM in UTC (day of month, hour, minute); effectiveStart and effectiveEnd give it as ISO 8601.
advisoryNumberNoThe advisory number read.
controlElementNoAirport/ARTCC pair or facility the advisory concerns, parsed from the title (SEA/ZSE, DCC); absent when the title has another form.
effectiveStartNoStart of the effective period, ISO 8601 UTC: the date nearest the advisory date with the printed start day of month (previous, same, or next month). Absent when effectiveTime is absent or names no real time.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedOutput schema / properties / effectiveEnd
      Added value: +{
      +  "description": "End of the effective period, ISO 8601 UTC: the first date at or after effectiveStart with the printed end day of month, in its month or the next. Present with effectiveStart.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / effectiveStart
      Added value: +{
      +  "description": "Start of the effective period, ISO 8601 UTC: the date nearest the advisory date with the printed start day of month (previous, same, or next month). Absent when effectiveTime is absent or names no real time.",
      +  "type": "string"
      +}
    • changedOutput schema / properties / effectiveTime / description
      Previous value: -"Effective period as the FAA prints it, DDHHMM-DDHHMM in UTC."New value: +"Effective period as the FAA prints it, DDHHMM-DDHHMM in UTC (day of month, hour, minute); effectiveStart and effectiveEnd give it as ISO 8601."
    • changedOutput schema / properties / sentAt / description
      Previous value: -"When the advisory was signed, as the FAA prints it: YY/MM/DD HH:MM in UTC."New value: +"When the advisory was signed, ISO 8601 UTC, as faa_delays_list_advisories gives its send time. Absent when the page prints no signature or it names no real minute."
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), and the description goes further by disclosing that advisory numbers restart at 1 each UTC day and that older advisories remain available — a real trap for an agent that assumes a globally unique identifier. It stops short of saying what happens when an advisory number is valid but the advisory does not exist for that date.

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?

Front-loaded with the action, then provenance, then the payoff for using this tool over the status feed, then a caveat about daily renumbering. Every sentence carries information, though the sentence enumerating four sibling tools and their reference fields is dense enough to slow reading.

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 values need not be specified, yet the description still previews the substantive fields (program rate by hour, delay assignment mode, scope, comments, active constraints, runway closures). With both parameters documented and provenance plus persistence behavior covered, an agent has everything needed 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 schema already documents accepted formats (MM/DD/YYYY, "ADVZY 082", "082") and the 1–999 range for both parameters. The description adds only the UTC qualification and the provenance hint, which is useful routing context but largely redundant against the schema text; baseline 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?

The description opens with a specific verb and resource: 'Get the full text of one ATCSCC advisory by its number and UTC date.' It immediately distinguishes itself from faa_delays_list_advisories, which is described as the listing counterpart, so an agent can pick between the two without inspecting 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?

It explicitly names where the required inputs come from (faa_delays_list_advisories rows, plus advisory references returned by faa_delays_list_active_events, faa_delays_get_airport_status, and faa_delays_get_operations_plan). It also states why an agent would reach for this tool rather than the status feed: advisory text carries rate-by-hour, delay assignment mode, scope, comments, and constraints that the status feed omits.

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.