Skip to main content
Glama
chrischall

flightaware-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

fa_get_flight_map

Generate a PNG flight map from a fa_flight_id. Save the image to disk or return it as base64, with optional width, height, and data overlay.

Instructions

Get a rendered map image (PNG) of a flight by fa_flight_id. Writes the PNG to disk (default: $AEROAPI_OUTPUT_DIR, else ~/Downloads/flightaware-mcp) and returns the path, or returns it inline as base64 when inline:true.

Input Schema

NameRequiredDescriptionDefault
idYesfa_flight_id of the flight
widthNoImage width in pixels
heightNoImage height in pixels
inlineNoReturn the PNG inline as base64 instead of writing to disk
output_dirNoDirectory to write the PNG to (default: $AEROAPI_OUTPUT_DIR, else ~/Downloads/flightaware-mcp). Must be inside that default directory.
show_data_blockNoOverlay the flight data block on the map

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.3.2
    • changedInput schema / properties / id / pattern
      Previous value: -"^[A-Za-z0-9.-]+$"New value: +"^[A-Za-z0-9][A-Za-z0-9.-]*$"
    • changedInput schema / properties / output_dir / description
      Previous value: -"Directory to write the PNG to (default: $AEROAPI_OUTPUT_DIR or cwd). When AEROAPI_OUTPUT_DIR is set, this must be inside it."New value: +"Directory to write the PNG to (default: $AEROAPI_OUTPUT_DIR, else ~/Downloads/flightaware-mcp). Must be inside that default directory."
  2. Changed1 schema field changedv1.2.3
    • changedInput schema / properties / output_dir / description
      Previous value: -"Directory to write the PNG to (default: $AEROAPI_OUTPUT_DIR or cwd)"New value: +"Directory to write the PNG to (default: $AEROAPI_OUTPUT_DIR or cwd). When AEROAPI_OUTPUT_DIR is set, this must be inside it."
  3. Changed1 schema field changedv1.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  4. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) hint that this is a non-destructive but side-effecting operation; the description concretely discloses the side effect (writing a PNG to disk) and the exact default location, which is valuable context beyond the flags. It could add more about overwrite behavior given idempotentHint=false, but it already adds real behavioral value.

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, front-loaded with the core purpose followed by return/side-effect behavior. Every clause earns its place with no 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?

With no output schema, the description carries the return-value burden and does so by naming both possible returns (file path or base64). It is nearly complete for a single-artifact tool, missing only minor details like repeated-call overwrite semantics.

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 all six parameters are already documented, making a 3 the baseline. The description restates the inline toggle and output_dir default, which the schema already conveys, adding little new syntax or edge-case meaning (e.g., how width/height interact with the render).

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?

States a specific verb and resource ('Get a rendered map image (PNG) of a flight') keyed by fa_flight_id, which clearly distinguishes it from sibling read tools like fa_get_flight_track and fa_get_flight_route. An agent can identify the exact artifact produced without opening 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?

Explains the two operating modes well: write-to-disk-by-default versus inline base64 when inline:true, which is the key invocation choice. However it gives no explicit when-to-use / when-not-to-use guidance relative to the other flight-visualization siblings, so it stops short of a full routing statement.

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