Skip to main content
Glama
chrischall

flightaware-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

fa_resolve_airport

Read-only

Resolve an airport code (ICAO, IATA, or LID) to its canonical AeroAPI identifier and alternate codes, enabling consistent airport lookup across flight data.

Instructions

Resolve an airport code to its canonical AeroAPI identifier (and equivalents). NOTE: requires a Standard or Premium AeroAPI tier — the free Personal tier returns 401.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesAirport code (ICAO/IATA/LID) to canonicalize
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact strips image/avatar URLs from the response; "full" returns FlightAware's payload untouched. No field projection: this server has no verified record of which FlightAware fields matter, and inventing one would risk dropping a field a caller needs.
id_typeNoDisambiguate how `id` is interpreted

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.2
    • addedInput schema / properties / view
      Added value: +{
+  "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact strips image/avatar URLs from the response; \"full\" returns FlightAware's payload untouched. No field projection: this server has no verified record of which FlightAware fields matter, and inventing one would risk dropping a field a caller needs.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  2. Addedv0.2.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds genuinely useful behavioral context beyond them: the canonicalization semantics and, critically, the auth failure mode ("the free Personal tier returns 401"). This is exactly the kind of failure information an agent needs up front. No contradiction 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.

Conciseness5/5

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

Two tightly written sentences: the core purpose is front-loaded, and the critical tier/401 caveat follows immediately. Every word earns its place; zero filler.

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?

Since there is no output schema, the description carries some burden for return values, and "canonical AeroAPI identifier (and equivalents)" plus the schema's detailed compact/full view semantics give the agent a workable picture of the response. Invocation requirements (id, optional id_type, tier prerequisite) are fully covered. A small gap: it never connects the resolved identifier to downstream airport tools, but nothing needed to call it 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 description coverage is 100%, including a notably thorough explanation of the view enum (compact vs. full and the explicit no-field-projection rationale). The description adds no new parameter semantics beyond restating the overall purpose, 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?

The description uses a specific verb ("Resolve") with a named resource ("airport code") and a precise outcome ("canonical AeroAPI identifier (and equivalents)"). This clearly distinguishes it from siblings like fa_get_airport (a lookup) and fa_resolve_flight (resolves flight codes), and an agent can tell its job from the first sentence.

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

Usage Guidelines3/5

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

The usage context is implied — an agent would reach for this when holding a raw airport code that needs canonicalizing — but no when-to-use/when-not-to-use guidance or alternative routing is given, despite ~30 siblings including closely related fa_get_airport and fa_resolve_flight. The tier note is a practical constraint rather than alternative-selection guidance.

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

Deploy Server

Other Tools