How do I use Flighty MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Flighty MCP Server What's my next flight?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Flighty MCP Server

by CPLX

Overview Schema Related Servers Score Discussions

TypeScript

Local

Flighty MCP Server

A zero-config MCP server that connects AI assistants to the Flighty flight tracking app. Ask about your flights, check statuses, look up delay forecasts, and add or remove flights — all through natural conversation.

Just install Flighty on your Mac and connect the server. It reads all credentials and configuration directly from the app — no API keys, no tokens, no setup.

What it does

This server gives any MCP-compatible AI assistant (Claude, etc.) full read/write access to your Flighty data:

"What's my current flight?" — shows in-progress, recently landed, and about-to-depart flights
"What's my next flight?" — returns the soonest upcoming flight first
"How often is AA179 delayed?" — historical on-time performance with percentage breakdowns
"Show my flight stats for 2025" — total flights, miles, top airlines, top routes
"Add DL10 on April 20" — adds the flight to your Flighty account, syncs to all devices within seconds
"Follow UA194 on December 25" — track someone else's flight (e.g. to pick them up), syncs to all devices
"Remove that flight" — deletes it from your account across all devices
"Are any friends flying soon?" — checks connected friends' upcoming flights
"What version of the Flighty tool is this?" — server info, capabilities, and version

Read operations query Flighty's local SQLite database directly (fast, offline-capable). Write operations call Flighty's API so changes sync to your phone, watch, and widgets. All responses include contextual metadata (sort order, timestamp format) to help AI assistants interpret results correctly.

Related MCP server: Google Flights MCP Server

Requirements

macOS — Flighty stores its database in the macOS app sandbox
Flighty macOS app — installed and signed in
Flighty Pro — required for the add/remove flight features
Node.js 24+ (only for manual install; the .mcpb bundle includes its own runtime)

Installation

Claude Desktop (.mcpb) — recommended

Download flighty-mcp-server.mcpb from the dist/ folder and double-click it. Claude Desktop installs it automatically. No configuration needed.

Claude Code

git clone https://github.com/CPLX/flighty-mcp-server.git
cd flighty-mcp-server
npm install
npm run build

Add to your MCP config (~/.claude/settings.local.json or project .mcp.json):

{
  "mcpServers": {
    "flighty": {
      "command": "node",
      "args": ["/absolute/path/to/flighty-mcp-server/build/index.js"]
    }
  }
}

Claude Desktop (manual)

Build from source as above, then add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "flighty": {
      "command": "node",
      "args": ["/absolute/path/to/flighty-mcp-server/build/index.js"]
    }
  }
}

Restart the client after adding the config.

Read-Only Mode

By default the server exposes 15 tools, including three that modify your Flighty account: flighty_add_flight, flighty_follow_flight, and flighty_remove_flight. If you only want Claude to read your flight data, you can disable the write tools so they don't appear in tools/list at all — the safest way to cap the blast radius.

Claude Desktop (.mcpb): during install, check the Read-Only Mode box. You can toggle it later from the extension's settings.

Claude Code / manual install: set the environment variable before launching the server. Add env to your MCP config:

{
  "mcpServers": {
    "flighty": {
      "command": "node",
      "args": ["/absolute/path/to/flighty-mcp-server/build/index.js"],
      "env": { "FLIGHTY_READ_ONLY": "1" }
    }
  }
}

Accepted truthy values: 1, true, yes (case-insensitive). Anything else (or unset) leaves write tools enabled. flighty_about reports the current mode.

If you use Flighty via someone else's account (shared through Flighty Friends), your locally signed-in Flighty account may own no flights itself — all the flights in the local database belong to the friend whose Flighty Pro account you're piggybacking on. In that setup, the server automatically falls back to picking the user with the most flights in the database. If your install has multiple people's flights and the server picks the wrong one, pin the correct user with an environment variable:

{
  "mcpServers": {
    "flighty": {
      "command": "node",
      "args": ["/absolute/path/to/flighty-mcp-server/build/index.js"],
      "env": { "FLIGHTY_OWNER_USER_ID": "the-userId-you-want" }
    }
  }
}

You can find the right userId by querying SELECT userId, COUNT(*) FROM UserFlight GROUP BY userId ORDER BY 2 DESC against ~/Library/Containers/com.flightyapp.flighty/Data/Documents/MainFlightyDatabase.db.

Tools

15 tools organized into four categories (12 read + 3 write; write tools are hidden when Read-Only Mode is on).

Flight Management

Tool	Description
`flighty_list_flights`	List your flights — upcoming (sorted soonest first), by year, or all (sorted most recent first)
`flighty_current_flights`	Active travel context: flights departing within ±24 hours of now
`flighty_get_flight`	Get details for a single flight by UUID or flight number (e.g., "AA179")
`flighty_search_flights`	Search your flight history by airline, airports, or date range
`flighty_add_flight`	Add a flight by code and date (e.g., "DL10" on "2026-04-20"). Syncs to all devices
`flighty_follow_flight`	Follow a flight without being a passenger (e.g., tracking someone's flight). Syncs to all devices
`flighty_remove_flight`	Remove a flight by UUID. Permanent deletion across all devices

Flight Intelligence

Tool	Description
`flighty_get_flight_status`	Current status (scheduled/delayed/in_air/landed/cancelled), gate, delay, weather
`flighty_get_delay_forecast`	Historical on-time stats: % early, on-time, late, cancelled, diverted
`flighty_get_flight_stats`	Aggregate stats: total flights, miles, circumnavigations, top airlines and routes
`flighty_get_connections`	Layover info for connecting flights: airports, duration, minimum connection time

Tool	Description
`flighty_list_friend_flights`	Connected friends' flights, filterable by name, upcoming, or year
`flighty_search_airports`	Search airports by IATA/ICAO code, city, or name
`flighty_search_airlines`	Search airlines by IATA/ICAO code, name, or alliance

Server Info

Tool	Description
`flighty_about`	Version, author, repository, capabilities, and requirements

Tool details

flighty_list_flights

Lists your flights with smart sort order based on the filter:

upcoming_only=true: sorted soonest first — the first result is your next flight
No filter or year: sorted most recent departure first (natural browsing order)

Parameters:

upcoming_only (boolean, default: false) — only flights with future departures, sorted soonest first
year (integer, optional) — filter to a specific year
limit (integer, 1-200, default: 50)
offset (integer, default: 0)

For flights currently in progress or recently landed, use flighty_current_flights instead.

Includes both auto-detected commercial flights and manually-entered flights (private/charter operators not in Flighty's commercial database, or commercial flights the user added by hand). Same applies to flighty_search_flights, flighty_get_flight, flighty_current_flights, flighty_get_flight_status, flighty_get_delay_forecast, flighty_get_flight_stats, and flighty_get_connections.

flighty_current_flights

Returns flights departing within 24 hours in either direction from now. Captures in-progress flights, recently landed flights (baggage claim, layovers), and flights about to depart.

No parameters. Sorted by departure time ascending (earliest first).

flighty_get_flight

Looks up a single flight by UUID or flight number.

Parameters (provide one):

flight_id (string) — internal Flighty UUID
flight_number (string) — e.g., "AA179", "DL10". If flown multiple times, returns the most recent instance

flighty_search_flights

Searches your flight history with combinable AND filters. Sorted most recent departure first.

Parameters (all optional):

airline — IATA code ("AA") or partial name ("American")
departure_airport — IATA code ("JFK") or city ("New York")
arrival_airport — IATA code ("SFO") or city ("San Francisco")
after — flights departing on or after this date ("2025-01-01")
before — flights departing on or before this date ("2025-12-31")
limit (integer, 1-200, default: 50)

flighty_get_flight_status

Returns the operational status of a flight that is already in the user's Flighty database. This only works for flights the user has added to Flighty — it cannot look up arbitrary flight numbers.

Parameters:

flight_number (string) — a flight in the user's database, e.g., "UA194"

Returns: Status ("scheduled", "delayed", "in_air", "landed", "cancelled"), departure/arrival delay in minutes, gate assignments, baggage belt, weather conditions, aircraft type, and tail number.

Data freshness depends on the Flighty app's last sync — this does not make live API calls for status.

flighty_get_delay_forecast

Historical on-time performance for a flight that is already in the user's Flighty database. Flighty attaches delay forecast data when a flight is added to the user's account — this tool reads that stored data. It cannot look up forecasts for arbitrary flight numbers that aren't in the database.

Parameters:

flight_number (string) — a flight in the user's database, e.g., "AA179"

Returns: Number of observations (sample size), mean delay in minutes, and percentage breakdowns: early, on-time, late (15/30/45+ min), cancelled, diverted. Returns null if no forecast data is available.

flighty_search_airports

Searches Flighty's airport database. Exact IATA/ICAO matches are prioritized over fuzzy name/city matches.

Parameters:

query (string) — IATA code, ICAO code, city name, or airport name
limit (integer, 1-50, default: 10)

flighty_search_airlines

Searches Flighty's airline database.

Parameters:

query (string) — IATA code, ICAO code, airline name, or alliance name
limit (integer, 1-50, default: 10)

flighty_get_flight_stats

Aggregate statistics across your flight history.

Parameters:

year (integer, optional) — filter to a specific year; omit for all-time

Returns: Total flights, distance (km and miles), earth circumnavigations, unique departure/arrival airports, unique airlines, countries_visited (deduped across departure and arrival countries), cancelled flight count, top 5 airlines, top 5 routes.

Includes both auto-detected commercial flights and manually-entered flights (e.g., private/charter operators not in Flighty's commercial database).

flighty_get_connections

Layover information for connecting flight pairs. Sorted by first leg departure time descending.

No parameters.

Returns: For each connection: inbound flight (first leg, e.g., "AA1449"), origin airport, connection airport, outbound flight (second leg, e.g., "AA1166"), destination airport, arrival/departure times, layover duration in minutes, and minimum connection time.

flighty_list_friend_flights

Flights from your Flighty-connected friends. Same sort behavior as list_flights — upcoming sorted soonest first, otherwise most recent first.

Parameters:

friend_name (string, optional) — partial match on name
upcoming_only (boolean, default: false) — future flights only, sorted soonest first
year (integer, optional)
limit (integer, 1-200, default: 50)
offset (integer, default: 0)

flighty_add_flight

Adds a flight to your Flighty account via the Flighty API. The flight syncs to all your devices (phone, watch, widgets) within seconds.

Parameters:

flight_code (string) — e.g., "DL10", "UA194". The 2-character airline prefix is parsed automatically
date (string) — departure date in YYYY-MM-DD format

Returns: The server-side flight UUID on success, or an error if the flight isn't found for that date.

flighty_follow_flight

Follows a flight without marking yourself as a passenger — use this to track someone else's flight (e.g., a family member's arrival). The flight is registered with Flighty's server and syncs to all devices. It will appear in flighty_list_friend_flights results (with friend_name as null).

Parameters:

flight_code (string) — e.g., "UA194", "DL10". The airline prefix is parsed automatically
date (string) — departure date in YYYY-MM-DD format

Returns: The server-side flight UUID on success, or an error if the flight isn't found for that date.

flighty_remove_flight

Permanently removes a flight from your Flighty account across all devices.

Parameters:

flight_id (string) — the flight UUID (from list_flights or add_flight results)

Warning: This cannot be undone. You would need to re-add the flight.

flighty_about

Returns server version, author, repository link, tool inventory, and requirements.

No parameters.

How it works

Flighty stores all flight data in a local SQLite database on macOS at:

~/Library/Containers/com.flightyapp.flighty/Data/Documents/MainFlightyDatabase.db

This server opens that database in read-only mode to answer queries. Queries UNION Flighty's Flight + ManualFlight and UserFlight + UserManualFlight tables so manually-entered flights surface alongside auto-detected commercial ones, and filter on UserFlight.isMyFlight = 1 so followed/tracked flights (isMyFlight = 0) don't leak into "your flights" queries. Followed flights (isMyFlight = 0) are surfaced by flighty_list_friend_flights alongside connected friends' flights. It reads all necessary credentials directly from the installed Flighty app:

User identity — JWT auth token from Flighty.sqlite (identifies the user to the API)
API access — build token from the app's Info.plist (identifies the app version)
Sync token — from the app's UserDefaults plist (for flight deletion)

For write operations (add/remove flights), the server makes the same API calls the Flighty app itself makes. Added flights get full enrichment from Flighty's servers — gate assignments, weather, delay forecasts, codeshare data — and sync to all devices. No manual configuration is needed.

All tool responses include a note field with contextual metadata (sort order, timestamp format) to help AI assistants interpret results correctly. All timestamps are UTC.

Architecture

src/
  index.ts              # Entry point, tool registration, flighty_about
  constants.ts          # Database paths, API config, build token (read from app)
  types.ts              # TypeScript interfaces
  services/
    database.ts         # FlightyDatabase — all SQLite read queries
    flighty-api.ts      # FlightyApi — search, subscribe, delete via Flighty API
  tools/
    flights.ts          # list, current, get, search flights
    flight-status.ts    # status, delay forecast
    friends.ts          # friend flights
    reference.ts        # airport/airline search
    stats.ts            # aggregate statistics
    connections.ts      # layover/connection info
    write.ts            # add_flight, remove_flight (API-backed)

Limitations

macOS only — relies on the Flighty macOS app's sandboxed data
Flighty app must be installed and signed in — the server reads its local databases for both flight data and authentication
Read data freshness — flight status data is as fresh as the Flighty app's last sync, not real-time
Write operations require network — add/remove flights call the Flighty API
Flighty API is private — this server uses Flighty's undocumented API, which could change in future app updates
Build token is read from the installed app — updates automatically when the app updates, but if Flighty changes where it stores the token, the server will need updating

License

MIT

Available Tools

14 tools

flighty_aboutAbout Flighty MCPA

Read-onlyIdempotent

Returns version, author, and capability information about this Flighty MCP server.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the tool returns version, author, and capability info, which is consistent and adds value beyond the 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?

A single, well-structured sentence that front-loads the purpose and provides necessary detail without any filler.

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?

Given no output schema, the description adequately explains the return value. The tool's behavior is simple and the description covers all necessary context for a metadata endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

The tool has no parameters, so schema coverage is 100%. Baseline for zero params is 4; the description does not need to add parameter info.

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 clearly states the tool returns version, author, and capability information, which is a specific verb+resource combination. It is distinct from sibling tools that deal with flight data.

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 description implies usage for obtaining server metadata, and no alternative tool exists for this purpose. However, explicit when-to-use or when-not-to-use guidance is not provided.

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

flighty_add_flightAdd FlightA

Add a flight to the user's Flighty account by flight code and date. The flight is registered with Flighty's server and syncs to all devices (phone, watch, etc.) within seconds.

The airline is detected from the flight code prefix (e.g. "DL" from "DL10"). The Flighty API provides full enrichment: gate assignments, weather, equipment, delay forecast, codeshare partners.

This tool calls the Flighty API — it requires the Flighty app to be installed and signed in.

Returns the server-side flight UUID on success.

ParametersJSON Schema

Name	Required	Description	Default
`flight_code`	Yes	Flight code, e.g. "DL10", "UA194", "BA930". The 2-character airline prefix is parsed automatically.
`date`	Yes	Departure date in YYYY-MM-DD format, e.g. "2026-04-15"

TDQS

A4/5.0

Behavior4/5

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

Annotations indicate non-read-only, non-destructive, non-idempotent, open-world. The description adds context: the flight is registered server-side, syncs across devices, and returns a UUID. It does not clarify duplicate behavior (idempotency) but provides good additional transparency.

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?

The description is four sentences, each serving a purpose: action, sync behavior, airline detection, prerequisites, return value. No wasted words, well-structured and front-loaded.

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?

For a simple 2-parameter tool with annotations, the description covers effect, sync, prerequisites, and return. It does not mention error states or duplicate handling, but is fairly complete overall.

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?

Input schema already has full descriptions for both parameters (100% coverage). The description reiterates the airline prefix parsing but adds no new meaning beyond the schema. Baseline 3 is appropriate.

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 clearly states the tool adds a flight to the user's Flighty account, using flight code and date. It specifies the resource and action, and ties to the tool name, distinguishing it from sibling tools like flighty_remove_flight.

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 description explains the prerequisites (Flighty app installed and signed in) and hints that the airline is auto-detected, but does not explicitly state when to use this tool over alternatives or what happens on duplicate calls, lacking explicit when-not guidance.

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

flighty_current_flightsCurrent FlightsA

Read-onlyIdempotent

Get the user's current travel context — flights departing within 24 hours in either direction from now. This captures in-progress flights, flights about to depart, and recently landed flights.

Use this when the user asks about their current flight, current trip, what gate they arrive at, baggage claim, layovers, or anything related to active travel. Use flighty_list_flights with upcoming_only=true for future travel planning instead.

Sorted by departure time ascending (earliest first). All timestamps are UTC.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already indicate read-only and idempotent. The description adds context about sorting by departure time and UTC timestamps, going beyond 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?

Three short sentences, each serving a purpose: what, when, and details. No redundancy.

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?

Despite no output schema, the description specifies sorting and timezone. Could mention if it returns only flights or additional details, but adequate for a simple query.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

No parameters exist, baseline is 4. The description adds value by explaining the 24-hour window and what flights are included.

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 clearly states the tool retrieves the user's current travel context within 24 hours, and distinguishes itself from siblings like flighty_list_flights for future planning.

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

Usage Guidelines5/5

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

Explicitly tells when to use (current flight, gate, baggage, layovers) and when not to (future planning), providing an alternative tool name.

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

flighty_get_connectionsGet Flight ConnectionsA

Read-onlyIdempotent

Get layover/connection information for the user's flights. Shows pairs of connecting flights, the connection airport, layover duration, and minimum connection time.

Results sorted by the first leg's departure time descending (most recent first). All timestamps are UTC.

Returns: id, inbound_flight (first leg, e.g. "AA1449"), from_airport, connection_airport, connection_airport_name, outbound_flight (second leg, e.g. "AA1166"), to_airport, arrival_time, departure_time, layover_minutes, min_connection_time_min.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

Annotations indicate readOnlyHint, destructiveHint, and idempotentHint, but the description adds behavioral context: results are sorted by departure time descending, timestamps are UTC, and it lists return fields. This provides value beyond 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?

The description is three sentences, front-loaded with the main purpose. It is concise with no unnecessary words, effectively conveying all necessary 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?

For a read-only tool with no parameters and strong annotations, the description is complete. It covers sorting, timezone, and return fields, which is sufficient for an agent to understand and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

The tool has no parameters, so the description cannot add parameter semantics. With 0 parameters, baseline is 4, and the description compensates by clearly detailing the output fields and format.

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 states 'Get layover/connection information for the user's flights,' clearly specifying the verb and resource. It distinguishes from sibling tools like flighty_get_flight or flighty_list_flights by focusing on connections.

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 tool's purpose is clear, but there is no explicit guidance on when to use it versus alternatives or when not to use it. The description implies usage for retrieving connections but lacks direct comparisons.

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

flighty_get_delay_forecastGet Delay ForecastA

Read-onlyIdempotent

Get historical delay statistics for a flight already in the user's Flighty database — how often it is early, on-time, late, cancelled, or diverted. This data is attached by Flighty when a flight is added to the user's account. It cannot look up forecasts for arbitrary flights not in the database.

Looks up the MOST RECENT instance of the flight to retrieve its stored delay forecast data. All timestamps are UTC.

Returns: flight_number, route (e.g. "SFO -> EWR"), observations (sample size), mean_delay_minutes, and percentage breakdowns (early_pct, ontime_pct, late_15/30/45_pct, cancelled_pct, diverted_pct). Returns null if no forecast data is available.

ParametersJSON Schema

Name	Required	Description	Default
`flight_number`	Yes	Flight number, e.g. "UA194"

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that returns null if no data, and lists the return fields, which provides useful context beyond annotations.

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

Conciseness4/5

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

Well-structured with purpose, constraints, and return details. Slightly verbose in listing percentages, but overall efficient and front-loaded.

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?

Despite no output schema, the description compensates by detailing the return fields. For a single-parameter tool, this is fully complete.

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 the description only repeats the flight_number format, adding no new semantic meaning beyond what the schema already provides.

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 clearly states it gets historical delay statistics for a flight already in the user's Flighty database, distinguishing it from tools like flighty_get_flight_status.

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

Usage Guidelines5/5

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

Explicitly states it only works for flights already in the database, not arbitrary ones, and specifies it looks up the most recent instance.

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

flighty_get_flightGet Flight DetailsA

Read-onlyIdempotent

Get detailed information about a single specific flight. Look up by either internal flight ID (UUID) or by flight number (e.g. "UA194").

Provide exactly one of flight_id or flight_number. If flight_number is provided and the user has flown that route multiple times, returns only the MOST RECENT instance. To see all instances, use flighty_search_flights with the airline filter instead.

All timestamps are UTC. Returns a single flight object, or null if not found.

ParametersJSON Schema

Name	Required	Description	Default
`flight_id`	No	Internal Flighty flight UUID
`flight_number`	No	Flight number, e.g. "UA194". Spaces, hyphens, and case are normalized.

TDQS

A4.4/5.0

Behavior4/5

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

Adds behavioral context beyond annotations: 'All timestamps are UTC', 'Returns a single flight object, or null if not found', and explains that flight_number returns most recent instance. No contradiction with annotations (readOnlyHint=true is consistent).

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?

Four sentences, each serving a purpose: purpose, parameter constraint, behavior with alternative, return format. No redundant language. Well-structured and front-loaded.

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?

Covers essential aspects: single result, null handling, UTC timestamps, parameter usage. Without an output schema, it mentions 'single flight object' but omits field details. Sufficient for low-complexity tool with good sibling differentiation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

Schema coverage is 100%, baseline 3. Description adds meaning by noting flight_id is internal UUID, flight_number is normalized, and enforces mutual exclusivity ('Provide exactly one of'), which is a constraint not present in the schema.

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?

Clearly states 'Get detailed information about a single specific flight', with verb 'Get' and resource 'flight'. Distinguishes from sibling flighty_search_flights by specifying single vs. multiple results and mentioning the alternative search tool.

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?

Explicitly instructs to provide exactly one of flight_id or flight_number, and directs to use flighty_search_flights when wanting all instances. Provides clear context but does not mention other siblings like flighty_get_flight_status for status-specific queries.

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

flighty_get_flight_statsGet Flight StatisticsA

Read-onlyIdempotent

Get aggregate statistics about the user's flight history: total flights, distance traveled, unique airports and airlines, top routes, and top airlines. Optionally filter to a specific year.

Includes all flights (past and upcoming). Distance is provided in both kilometers and miles.

ParametersJSON Schema

Name	Required	Description	Default
`year`	No	Filter to a specific year (e.g. 2025). Omit for all-time stats.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations indicate read-only, nondestructive, and idempotent behavior. The description adds that it includes all flights (past and upcoming) and that distance is provided in both km and miles, which is useful beyond the 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?

Three concise sentences: first lists what stats are returned, second mentions optional filter, third clarifies scope and output units. No wasted words.

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?

The description covers the output contents and format. With no output schema, this is sufficient for a simple stats tool. It doesn't mention error conditions, but the scope is clear.

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?

The only parameter (year) has 100% schema description coverage. The description reiterates the optional filter and gives an example, adding minimal value over the schema.

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 clearly states it returns aggregate statistics about the user's flight history, listing specific metrics (total flights, distance, unique airports/airlines, top routes, top airlines). This is distinct from sibling tools like flighty_get_flight (single flight) and flighty_list_flights (list of flights).

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 description tells users they can optionally filter by year. It doesn't explicitly state when not to use this tool or name alternatives, but the context is clear given sibling tool names.

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

flighty_get_flight_statusGet Flight StatusA

Read-onlyIdempotent

Get the current operational status of a flight already in the user's Flighty database, including delay information, gate assignments, weather, and aircraft details. This only works for flights the user has added to Flighty. Looks up the MOST RECENT instance of the given flight number.

Status values: "scheduled", "delayed" (departure delay > 15 min), "in_air" (departed but not arrived), "landed", or "cancelled".

Data freshness depends on the Flighty app's last sync — this does NOT make live API calls. All timestamps are UTC.

Returns: flight_number, status, is_cancelled, departure/arrival airports, scheduled/estimated/actual times, delay minutes, gate info, weather, aircraft.

ParametersJSON Schema

Name	Required	Description	Default
`flight_number`	Yes	Flight number, e.g. "UA194", "BA930"

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds significant behavioral context: data freshness depends on last sync (no live API), status values, UTC timestamps, and a comprehensive list of returned fields. 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?

The description is concise, with each sentence adding value. It is front-loaded with the core purpose, followed by constraints, status values, data freshness, and return fields. No unnecessary words.

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?

Given the tool has only one parameter, no output schema, and clear annotations, the description covers all necessary context: what it does, constraints, behavior, and return fields. It is complete and sufficient for an agent to use correctly.

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?

The schema already describes the single parameter with an example, achieving 100% coverage. The description does not add extra detail about the parameter beyond what is in the schema, so 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 clearly states the tool gets current operational status of a flight from the user's database, specifying it only works for flights already added and looks up the most recent instance. This distinguishes it from sibling tools like flighty_get_flight and flighty_current_flights.

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 description explicitly states the constraint that it only works for flights the user has added to Flighty, and that it retrieves the most recent instance. It does not explicitly mention when not to use, but the constraint provides clear context for appropriate usage.

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

flighty_list_flightsList My FlightsA

Read-onlyIdempotent

List the user's flights from Flighty. Does NOT include friends' flights (use flighty_list_friend_flights for that).

Filtering:

No filter: returns ALL flights (upcoming + past), sorted by departure date descending (most recent first)
upcoming_only=true: only flights with future departures, sorted soonest first — the first result is the user's next flight
year=2025: only flights from that year, sorted descending (matches the app's past-by-year view)

NOTE: upcoming_only only returns flights that have not yet departed. For the user's current travel context (in-progress flights, recently landed, about to depart), use flighty_current_flights instead.

All timestamps are UTC.

ParametersJSON Schema

Name	Required	Description
`upcoming_only`	No	Only return flights departing in the future (sorted soonest first)
`year`	No	Filter to a specific year (e.g. 2025). Shows past flights from that year, matching the Flighty app's year view.
`limit`	No	Maximum number of flights to return
`offset`	No	Number of flights to skip for pagination

TDQS

A4.9/5.0

Behavior5/5

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

Description adds behavioral details beyond annotations: default sorting (descending by departure date), effect of upcoming_only on sort order (soonest first), year filter matching app view, and that all timestamps are UTC. Annotations already confirm read-only, non-destructive, idempotent; description adds value without contradiction.

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?

Description is concise (4 sentences plus bullet-like lines). Purpose is front-loaded, followed by exclusions and filtering details. Every sentence serves a purpose. No fluff.

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?

Given 4 optional parameters, no required ones, read-only hints, and no output schema, the description covers all needed behavioral aspects: default behavior, sorting, timezone, handling of upcoming_only vs current flights, and ties to sibling tools. It's complete for an AI agent to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

Schema covers all 4 parameters (100% coverage). Description adds extra context: for upcoming_only, clarifies it only returns not-yet-departed flights; for year, adds sorting descending. These go beyond the schema's descriptions, but limit and offset are not elaborated further. Overall useful but not extensive.

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?

Description clearly states it lists user's flights from Flighty, specifies it excludes friends' flights, and points to the sibling tool flighty_list_friend_flights for that purpose. It also distinguishes from flighty_current_flights via a note. The verb 'list' and resource 'user's flights' are precise.

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

Usage Guidelines5/5

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

Explicitly tells when to use this tool (list user's flights) and when not to (for friends' flights or current travel context), providing exact sibling tools (flighty_list_friend_flights, flighty_current_flights). Also explains filtering scenarios like upcoming_only and year filter with expected sorting behavior.

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

flighty_list_friend_flightsList Friend FlightsA

Read-onlyIdempotent

List flights belonging to the user's connected friends in Flighty. Excludes the user's own flights (use flighty_list_flights for those).

Same filtering as flighty_list_flights:

No filter: all friend flights, sorted descending (most recent first)
upcoming_only=true: future flights only, sorted soonest first — the first result is the friend's next flight
year=2025: flights from that year, sorted descending

All timestamps are UTC. Returns the same flight schema as flighty_list_flights, plus a friend_name field.

ParametersJSON Schema

Name	Required	Description
`friend_name`	No	Filter by friend's name (partial, case-insensitive match on full name or first name)
`upcoming_only`	No	Only future flights (sorted soonest first)
`year`	No	Filter to a specific year (e.g. 2025)
`limit`	No	Maximum results
`offset`	No	Pagination offset

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already indicate readOnly, non-destructive, idempotent. Description adds useful context: timestamps in UTC, return schema includes friend_name, sorting based on filter. No contradictions.

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?

Concise and well-structured with bullet points for filtering options. Every sentence adds value; no unnecessary text.

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?

No output schema, but description explains return format (same as flighty_list_flights plus friend_name). Adequate for a list tool with many siblings; covers key behavioral aspects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

Schema coverage is 100%, but description adds value by explaining friend_name matching (partial, case-insensitive) and the sorting implication of upcoming_only and year.

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 clearly states it lists flights belonging to connected friends, explicitly excludes user's own flights, and distinguishes from the sibling tool flighty_list_flights.

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

Usage Guidelines5/5

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

Provides explicit guidance on when to use this tool versus flighty_list_flights, and describes filtering behaviors for no filter, upcoming_only, and year parameters.

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

flighty_remove_flightRemove FlightA

DestructiveIdempotent

Remove a flight from the user's Flighty account. The flight is deleted from the server and the deletion syncs to all devices.

Provide the flight UUID (from flighty_list_flights or flighty_add_flight results). This is the server-side UUID, not the flight number.

WARNING: This permanently removes the flight from your Flighty account across all devices. This cannot be undone — you would need to re-add the flight.

ParametersJSON Schema

Name	Required	Description	Default
`flight_id`	Yes	The flight UUID to remove (from list_flights results)

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds critical context: 'deletion syncs to all devices' and a clear warning that the action is permanent and cannot be undone. This fully discloses behavioral traits beyond the 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?

Description is three concise sentences plus a one-line warning. No extraneous information. The core action is front-loaded, and the parameter guidance and warning follow logically.

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?

For a simple tool with one parameter and no output schema, the description covers all necessary aspects: what it does, what input to provide, and what the consequences are (permanent deletion, sync across devices). No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

The input schema has one parameter with a description. The description adds extra meaning by specifying 'This is the server-side UUID, not the flight number.' Schema coverage is 100%, but the description provides a valuable clarification.

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 clearly states 'Remove a flight from the user's Flighty account' with specific verb ('Remove') and resource ('flight'). It distinguishes from sibling tools like flighty_add_flight or flighty_list_flights by focusing on deletion.

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?

Explicitly tells the user to provide the flight UUID from specific sources (flighty_list_flights or flighty_add_flight) and clarifies it's the server-side UUID, not flight number. A warning about permanence is included. Could add when not to use (e.g., if only want to cancel sync), but current guidance is sufficient.

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

flighty_search_airlinesSearch AirlinesA

Read-onlyIdempotent

Search the Flighty airline database by IATA code, ICAO code, airline name, or alliance. Sorted by relevance.

Returns: id, name, iata, icao, alliance, website, callsign, formattedPhone.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search term — IATA code (e.g. "UA"), ICAO (e.g. "UAL"), name (e.g. "United"), or alliance (e.g. "Star Alliance")
`limit`	No	Maximum results

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds value by listing the return fields (id, name, iata, icao, alliance, website, callsign, formattedPhone) and stating sorting by relevance. No contradictions.

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?

The description is two sentences, front-loading the purpose and quickly listing return fields. Every sentence is necessary and no fluff. Efficient and to the point.

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?

Given the tool's simplicity (2 params, no output schema), the description covers the essential aspects: search criteria, return fields, and sorting. Could briefly mention pagination but not required for completeness. Annotations fill safety profile.

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?

Input schema covers both parameters with 100% coverage. Description reinforces the query parameter's meaning but adds no new parameter details. The sorting info is relevant but beyond param semantics. Baseline score is appropriate.

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 clearly states the action ('Search'), the resource ('Flighty airline database'), and the search criteria ('by IATA code, ICAO code, airline name, or alliance'). It effectively distinguishes from sibling tools that search airports or flights.

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 description provides clear inputs but does not explicitly state when to use this tool versus alternatives. Usage is implied but lacks exclusion criteria or context for when not to use.

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

flighty_search_airportsSearch AirportsA

Read-onlyIdempotent

Search the Flighty airport database by IATA code, ICAO code, airport name, or city name. Sorted by relevance (major airports first).

Returns: id, name, iata, icao, city, country, countryCode, timeZoneIdentifier, latitude, longitude, website.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search term — IATA code (e.g. "SFO"), ICAO (e.g. "KSFO"), city (e.g. "San Francisco"), or name (e.g. "Heathrow")
`limit`	No	Maximum results

TDQS

A4.5/5.0

Behavior4/5

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

Annotations indicate read-only, non-destructive, idempotent behavior. The description adds that results are sorted by relevance (major airports first) and lists return fields, providing context beyond 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 brief sentences in the first paragraph cover purpose and behavior; a second paragraph lists return fields. No redundant information; every sentence earns its place.

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?

For a simple search tool with no output schema, the description provides all necessary context: search parameters, sorting, and return fields. No gaps given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

Schema covers both parameters with detailed descriptions. The description adds meaning by mentioning sorting by relevance, which is not in schema. With 100% schema coverage, baseline is 3; the added value warrants a 4.

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 clearly states the tool searches airport data by IATA, ICAO, name, or city, and distinguishes it from siblings like flighty_search_airlines and flighty_search_flights. It specifies sorting by relevance, which is unique to this tool.

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 description implicitly guides when to use (searching airports) but does not explicitly mention when not to use or compare with alternatives. However, the sibling tools are distinct enough that usage context is clear.

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

flighty_search_flightsSearch FlightsA

Read-onlyIdempotent

Search the user's flight history by airline, departure/arrival airports, or date range. All filters are optional and combine with AND logic.

Results sorted by departure date descending (most recent first). All timestamps are UTC.

Airport filters match by IATA code (exact, case-insensitive) OR by city name (partial, case-insensitive). Airline filter matches by IATA code (exact) OR airline name (partial).

ParametersJSON Schema

Name	Required	Description
`airline`	No	Airline IATA code (e.g. "UA") or partial name (e.g. "United")
`departure_airport`	No	Departure airport IATA code (e.g. "SFO") or city (e.g. "San Francisco")
`arrival_airport`	No	Arrival airport IATA code (e.g. "LHR") or city (e.g. "London")
`after`	No	Only flights departing on or after this date (e.g. "2025-01-01")
`before`	No	Only flights departing on or before this date (e.g. "2025-12-31")
`limit`	No	Maximum results

TDQS

A4.6/5.0

Behavior5/5

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

Beyond annotations (readOnlyHint, destructiveHint, idempotentHint), the description adds valuable behavioral details: results sorted by departure date descending, timestamps in UTC, and matching logic for airports and airlines (IATA code vs. partial name, case-insensitivity).

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?

The description is very concise, with three short paragraphs. Each sentence adds value, and the most important information (purpose) is front-loaded. No unnecessary words.

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?

Given six optional parameters and no output schema, the description covers search behavior, sorting, timezone, and matching logic. It could briefly mention the return type (e.g., list of flights with key fields), but overall it is sufficient for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

Schema coverage is 100% with good descriptions, but the description adds extra semantic detail about how filters match (e.g., airport filters match IATA code exact or city name partial, airline matches IATA exact or airline name partial). This justifies above the baseline of 3.

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-resource combination ('Search the user's flight history') and distinguishes from sibling tools by noting the search and filter capabilities, which set it apart from listing or individual flight retrieval tools.

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 description states that all filters are optional and combine with AND logic, providing clear context. However, it does not explicitly mention when to avoid this tool in favor of siblings (e.g., for a single flight, use get_flight).

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, but some potential overlap exists (e.g., flighty_get_flight vs flighty_get_flight_status, flighty_current_flights vs flighty_list_flights). Descriptions help differentiate, but an agent might occasionally misselect.

Naming Consistency4/5

All tools use the 'flighty_' prefix and mostly follow verb_noun pattern. 'flighty_about' and 'flighty_current_flights' are minor deviations, but overall the pattern is predictable and consistent.

Tool Count5/5

14 tools is well-scoped for a flight tracking server. Each tool serves a distinct need (CRUD, search, status, stats, connections, friend sharing) without being overwhelming or sparse.

Completeness5/5

The tool surface covers core flight tracking operations: add/remove, list/search, status, delay forecast, statistics, connections, and friend flights. Missing update/modify is appropriate as flights are synced automatically. No obvious gaps.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Pointify Travel A
com.pointifytravels
Search award flights and cash fares, optimize points, and predict fares inside ChatGPT and Claude.
Travel & Transportation Finance
52
Pro Flight Search Airport Delays A
com.proflightsearch
Read-only airport delay, weather, and 24h forecast tools for AI assistants. Airport-level only.
Travel & Transportation Weather Services
42
Journi Travel
io.github.ama353-arch
Personal AI travel agent. Points optimization, live flight/hotel/award search, trip planning.
Travel & Transportation Search
2
Nowah Travel
io.github.Nowah-xyz
Your personal AI travel concierge — flights, hotels, 116M+ POIs, visas, weather & more
Travel & Transportation Search Weather Services
2

Related MCP Servers

AirTrail MCP Server
Travel & Transportation Search
maboukerfa
F
license
C
quality
D
maintenance
Enables AI assistants to manage a self-hosted AirTrail flight tracking instance, providing natural language access to flight data, travel history, and statistics.
Updated 10 months ago (2025-11-11 15:22 UTC)
3
3
Google Flights MCP Server
Travel & Transportation Search
smamidipaka6
A
license
A
quality
F
maintenance
Connects AI agents to Google Flights data, enabling retrieval of flight information, cheapest options, time-filtered flights, and best recommendations.
Updated a year ago (2025-03-27 17:27 UTC)
4
28
MIT
Flighty MCP
Travel & Transportation Search
LukasHaas
A
license
Not graded
quality
C
maintenance
Enables AI assistants to access and manage your Flighty flight data directly from the local macOS app database, supporting flight lists, status, searches, additions, and more.
Updated 6 days ago (2026-08-28 14:04 UTC)
15
MIT
Flightradar24 MCP Serverofficial
Travel & Transportation Location Services
Flightradar24
A
license
A
quality
C
maintenance
Provides real-time and historical flight data via the Flightradar24 API, enabling AI assistants to track aircraft positions, flight summaries, and airport details.
Updated 7 months ago (2026-01-22 10:17 UTC)
15
123
24
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CPLX/flighty-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Flighty MCP Server

What it does

Requirements

Installation

Claude Desktop (.mcpb) — recommended

Claude Code

Claude Desktop (manual)

Read-Only Mode

Friend-Share Installs

Tools

Flight Management

Flight Intelligence

Social and Reference

Server Info

Tool details

flighty_list_flights

flighty_current_flights

flighty_get_flight

flighty_search_flights

flighty_get_flight_status

flighty_get_delay_forecast

flighty_search_airports

flighty_search_airlines

flighty_get_flight_stats

flighty_get_connections

flighty_list_friend_flights

flighty_add_flight

flighty_follow_flight

flighty_remove_flight

flighty_about

How it works

Architecture

Limitations

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Flightradar24 MCP Serverofficial

Latest Blog Posts

MCP directory API