faa-traffic-delays-mcp-server

Get FAA Operations Plan

faa_delays_get_operations_plan

Read-onlyIdempotent

Get the FAA Command Center's current operations plan: terminal programs (possible ground stops and delay programs by airport) and en-route initiatives (route closures, severe-weather avoidance plans) expected later in the day, each with its planned UTC time and stated likelihood, plus current ATCSCC announcements. The advisory reference opens the full plan text with faa_delays_get_advisory, including active constraints and runway closures this summary omits.

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_get_operations_plan"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Guidance on an empty plan, a missing advisory link, or partial data.
`advisory`	No	Reference to the ATCSCC advisory behind this item, absent when the FAA feed links none. For the full text, call faa_delays_get_advisory with number as advisory_number and date as date.
`fetchedAt`	No	When this server fetched the operations plan from the FAA (UTC ISO); with the 60 s cache it can trail the call by up to a minute.
`announcements`	No	Current ATCSCC announcements; [] when there are none, absent when that FAA list could not be read.
`enRoutePlanned`	No	En-route initiatives the FAA expects later today: route closures, severe-weather avoidance plans (SWAP), and coded departure routes (CDRs), in plan order.
`terminalPlanned`	No	Terminal programs the FAA expects later today: possible ground stops and delay programs by airport, in plan order.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 4, 2026

changedOutput schema / properties / terminalPlanned / items / description

Previous value: -"One planned program or initiative."New value: +"One planned terminal program."

addedOutput schema / properties / terminalPlanned / items / properties / airports

Added value: +{
+  "description": "Airports this item names, in text order: the identifier group before GROUND (SEA/BFI gives SEA and BFI), each a code in the bundled FAA NASR directory, as faa_delays_get_airport_status accepts it. Absent when the item names none the directory lists, such as a metro area or an ARTCC.",
+  "items": {
+    "description": "FAA 3-character airport identifier.",
+    "type": "string"
+  },
+  "type": "array"
+}

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, openWorld, and idempotent, so the safety profile is covered. The description adds genuinely useful context beyond them: the content is forward-looking ('expected later in the day'), carries stated likelihoods, and is explicitly an incomplete summary that omits active constraints and runway closures — a real caveat for downstream reasoning.

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 the action and resource, then the detailed contents, ending with the sibling pointer. The second sentence is dense with parenthetical lists but every element carries information an agent needs to interpret the output.

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 and no parameters, the description needs only to explain scope, forecast semantics, and where the omitted data lives — all of which it does. An agent can decide to call it and interpret the response without further information.

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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. The description correctly implies a no-argument global snapshot.

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?

Specific verb plus resource ('Get the FAA Command Center's current operations plan') followed by concrete contents: terminal programs (ground stops, delay programs by airport), en-route initiatives (route closures, weather avoidance), planned UTC times, likelihoods, and ATCSCC announcements. It is clearly differentiated from the sibling faa_delays_get_advisory, which is named as the source of the full plan text.

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

Usage Guidelines4/5

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

It gives clear routing guidance: this tool returns a summary, and the advisory reference should be used with faa_delays_get_advisory to open the full plan text including constraints and runway closures omitted here. It does not explicitly contrast with airport_status or list_advisories, but the use condition for this tool is stated plainly.

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.