Skip to main content
Glama
Sign In

Pro Flight Search Airport Delays

by com.proflightsearch
OverviewDiscussionsAdmin

Get airport delay status

get_airport_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. Airport-level only, not flight-number tracking.

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.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive behaviour, so the description is not burdened with the safety profile. It adds genuine behavioural context beyond them: the data is live, the forecast/outlook is conditional ('when one is published'), and coverage is per-airport rather than per-flight. It does not discuss failure modes for an unrecognized airport, which keeps it short of a 5.

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?

Two compact sentences, front-loaded with the core capability and ending with the scoping exclusion. No filler, no repetition of the title, and every clause contributes information.

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 describe return values; what remains — data freshness, per-airport scope, accepted input forms, conditional forecast availability, and the flight-tracking exclusion — is all covered. 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.

Parameters3/5

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

Schema coverage is 100% and both parameters already carry descriptions and an enum for format, so the schema does the heavy lifting. The description restates the accepted identifier forms but adds no syntax, normalization, or disambiguation rule beyond what the schema examples already provide.

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?

Starts with a specific verb ('Get') and a precisely scoped resource: live airport-level delay, cancellation and weather flight-rules, plus optional forecast and departure outlook. The final sentence explicitly negates flight-number tracking, so an agent can distinguish this from a flight-status tool without reading the 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?

Clearly states the usage boundary ('Airport-level only, not flight-number tracking') and enumerates acceptable identifier forms (IATA code, city, airport name). It stops short of naming a concrete alternative sibling such as search_supported_airports for an unfound airport, so it is clear but not fully routing.

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