Read-only airport delay, weather, and 24h forecast tools for AI assistants. Airport-level only.
Scored across 4 tools
The tool set contains two exact duplicate pairs: airport.get_delay_status duplicates get_airport_delay_status, and airport.search_supported duplicates search_supported_airports. Descriptions admit these are aliases, but an agent must still choose between functionally identical tools, creating selection noise.
Half the tools use dot-notation (airport.get_delay_status, airport.search_supported) and half use snake_case (get_airport_delay_status, search_supported_airports). This mixed convention is exactly what causes ambiguity when two styles describe the same operation.
Although the advertised count is 4, only 2 unique operations exist due to alias duplication. That leaves an extremely thin surface for the stated purpose, with the tool list inflated by redundant entries.
The narrow domain (airport delay status plus airport code lookup) is covered, but there are no operations for multi-airport comparison, historical delays, or related lifecycle features. Search plus status is a workable minimum, though limited.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format. Use plain for SMS-style replies; markdown includes formatted links. Defaults to plain. | |
| airport | Yes | Airport IATA code, city, or airport name. Examples: JFK, LHR, Copenhagen, Chicago O'Hare. |
| Name | Required | Description |
|---|---|---|
| scope | Yes | Current data scope for the tool result. |
| format | Yes | Returned text format. |
| airport | Yes | Resolved airport IATA code. |
| tomorrow | No | 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. |
| detailsUrl | Yes | Pro Flight Search airport details URL for citation or follow-up. |
| disclaimer | Yes | Operational-data disclaimer for the airport status. |
| statusText | Yes | Airport status text returned in the MCP content block. |
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.
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.
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.
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.
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.
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.
Search Pro Flight Search tracked airports when a user's airport reference is ambiguous. Returns matching IATA codes to use with airport.get_delay_status. Alias of search_supported_airports for clients that prefer dot-notation tool names.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Airport code, city, or airport name to search. Examples: London, Paris, Chicago, ORD. |
| Name | Required | Description |
|---|---|---|
| query | Yes | Search query used to find tracked airports. |
| matches | Yes | Tracked airport matches that can be used with get_airport_delay_status or airport.get_delay_status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety profile is clear. Description adds behavioral context: it searches tracked airports and returns IATA codes, which aligns with annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, no redundant information. Every sentence contributes to understanding the tool's purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of annotations and output schema, the description covers purpose, input, expected result (matching IATA codes), and relationship to sibling tool. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'query' described. Description adds value by providing concrete examples (London, Paris, Chicago, ORD) and clarifying accepted input types: airport code, city, or airport name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Search', the resource 'supported airports', and the context 'when a user's airport reference is ambiguous'. It distinguishes from sibling tools by noting it returns IATA codes for use with airport.get_delay_status, and mentions it's an alias of search_supported_airports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description specifies when to use: when an airport reference is ambiguous, and what to do with results: use with airport.get_delay_status. It does not explicitly state when not to use or compare with non-sibling alternatives, but provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format. Use plain for SMS-style replies; markdown includes formatted links. Defaults to plain. | |
| airport | Yes | Airport IATA code, city, or airport name. Examples: JFK, LHR, Copenhagen, Chicago O'Hare. |
| Name | Required | Description |
|---|---|---|
| scope | Yes | Current data scope for the tool result. |
| format | Yes | Returned text format. |
| airport | Yes | Resolved airport IATA code. |
| tomorrow | No | 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. |
| detailsUrl | Yes | Pro Flight Search airport details URL for citation or follow-up. |
| disclaimer | Yes | Operational-data disclaimer for the airport status. |
| statusText | Yes | Airport status text returned in the MCP content block. |
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.
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.
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.
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.
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.
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.
Search Pro Flight Search tracked airports when a user's airport reference is ambiguous. Returns matching IATA codes to use with get_airport_delay_status. Call this before airport status when the user says a city name like London or Chicago.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Airport code, city, or airport name to search. Examples: London, Paris, Chicago, ORD. |
| Name | Required | Description |
|---|---|---|
| query | Yes | Search query used to find tracked airports. |
| matches | Yes | Tracked airport matches that can be used with get_airport_delay_status or airport.get_delay_status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds that it returns matching IATA codes and the intended flow, consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with verb and resource, then usage guidance. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a search tool with output schema. Explains trigger and downstream tool. Could mention ordering or limits but not necessary given output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the parameter with examples. Description adds context but does not significantly enhance beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool searches tracked airports when ambiguous and returns IATA codes for get_airport_delay_status. It distinguishes from siblings by specifying when to call it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear usage context: call when user's airport reference is ambiguous, before airport status for city names. Does not explicitly state when not to use but provides solid guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
airport.get_delay_status1 field changedOutput schema / properties / tomorrow / descriptionPrevious 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."get_airport_delay_status1 field changedOutput schema / properties / tomorrow / descriptionPrevious 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."airport.get_delay_status1 field changedOutput schema / properties / tomorrowAdded 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"
+ ]
+}get_airport_delay_status1 field changedOutput schema / properties / tomorrowAdded 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"
+ ]
+}airport.get_delay_statusairport.search_supportedget_airport_delay_statussearch_supported_airportsAirport METAR/TAF weather and FAA delays by airport code. $0.003/call via x402.
Flight and sky conditions for agents, from METAR/TAF and airports to aurora and satellite passes.
Track FAA ground stops, delay programs, airport delays, the operations plan, and ATCSCC advisories.
FAA Delays MCP — live US airport operational status (FAA, free, no auth).
Add one secure layer between your agents and this server.