Skip to main content
Glama
Sign In

Pro Flight Search Airport Delays

by com.proflightsearch
OverviewDiscussionsAdmin

Get airport delay status

airport.get_delay_status
Read-onlyIdempotent

Get live airport-level delay, cancellation, and weather flight-rules for one airport, plus tomorrow's forecast and departure outlook when one is published. Accepts IATA code, city, or airport name. Alias of get_airport_delay_status for clients that prefer dot-notation tool names.

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": {
      "airport": "<airport>"
    },
    "name": "airport.get_delay_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
formatNoOutput format. Use plain for SMS-style replies; markdown includes formatted links. Defaults to plain.
airportYesAirport IATA code, city, or airport name. Examples: JFK, LHR, Copenhagen, Chicago O'Hare.

Output Schema

NameRequiredDescriptionDefault
scopeYesCurrent data scope for the tool result.
formatYesReturned text format.
airportYesResolved airport IATA code.
tomorrowNoTomorrow at this airport, on its local date, from the GateWeather feeds: forecast (high and low in °C with the likely range, chances 0 to 1, wind in kt), departure outlook (predicted percent of departures cancelled or leaving 60+ min late, against the airport's usual percent, with a level and the weather drivers) and source to credit, with any credit lines its data require (show them with the numbers). A forecast, never a measurement. Null when no fresh outlook exists; null never means normal.
detailsUrlYesPro Flight Search airport details URL for citation or follow-up.
disclaimerYesOperational-data disclaimer for the airport status.
statusTextYesAirport status text returned in the MCP content block.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / tomorrow / description
      Previous value: -"Tomorrow at this airport, on its local date, from the WeatherTomorrow feeds: forecast (high and low in °C with the likely range, chances 0 to 1, wind in kt), departure outlook (predicted percent of departures cancelled or leaving 60+ min late, against the airport's usual percent, with a level and the weather drivers) and source to credit, with any credit lines its data require (show them with the numbers). A forecast, never a measurement. Null when no fresh outlook exists; null never means normal."New value: +"Tomorrow at this airport, on its local date, from the GateWeather feeds: forecast (high and low in °C with the likely range, chances 0 to 1, wind in kt), departure outlook (predicted percent of departures cancelled or leaving 60+ min late, against the airport's usual percent, with a level and the weather drivers) and source to credit, with any credit lines its data require (show them with the numbers). A forecast, never a measurement. Null when no fresh outlook exists; null never means normal."
  2. Changed1 schema field changed
    • addedOutput schema / properties / tomorrow
      Added value: +{
+  "description": "Tomorrow at this airport, on its local date, from the WeatherTomorrow feeds: forecast (high and low in °C with the likely range, chances 0 to 1, wind in kt), departure outlook (predicted percent of departures cancelled or leaving 60+ min late, against the airport's usual percent, with a level and the weather drivers) and source to credit, with any credit lines its data require (show them with the numbers). A forecast, never a measurement. Null when no fresh outlook exists; null never means normal.",
+  "type": [
+    "object",
+    "null"
+  ]
+}
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new context: the data is live, tomorrow's forecast and departure outlook are included but conditional ('when one is published'). No auth or rate-limit notes, which is the main residual gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the outcome then the input contract then the aliasing note. Nothing is redundant with the title and every sentence carries distinct information.

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

Completeness4/5

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

Output schema exists, so return values need no explanation, and annotations cover the safety profile. Scope, input flexibility, aliasing, and conditional forecast availability are all present; only operational details like data freshness or coverage limits are absent, which is minor for a read-only lookup.

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%, so both parameters are already documented, including the format enum and its plain-vs-markdown tradeoff. The description restates the accepted airport identifier forms but adds no syntax or format guidance beyond the schema, so the 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?

Names a specific verb and resource set: live airport delay, cancellation, weather flight-rules, plus tomorrow's forecast. It also disambiguates itself from the sibling get_airport_delay_status by declaring it an alias, so an agent can tell the pair apart 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 Guidelines4/5

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

The alias sentence gives a clear selection rule (dot-notation-preferring clients), and 'Accepts IATA code, city, or airport name' tells the agent what input shapes are valid. It stops short of an explicit 'use X instead when Y', but the alias framing makes the alternative obvious.

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

All Pro Flight Search Airport Delays toolsInspect
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.

Resources