Skip to main content
Glama
Sign In
FlightByte MCP Server

FlightByte MCP Server

Official
by FlightByte-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Search flights

search_flights
Read-only

Look up live flight status by carrier, flight number, and date; returns gates, delays, and alternate legs, with origin/destination to select a specific leg.

Instructions

The same lookup as get_flight (same parameters, same snapshot), sent as query parameters to /v1/flights/search. Use either one, not both. Returns FlightByte's flight snapshot: status.phase to branch on (scheduled, boarding, departed, en_route, landed, arrived, cancelled, diverted, redirected, unknown) with delayed/cancelled/diverted flags; departure and arrival airports with terminal, gate and baggage carousel; scheduled, estimated and actual gate and runway times in UTC and local time (bestTimeUtc is the best single time, delayMinutes the gate delay); aircraft, codeshares, the airline timeline, cached, and alternates: every leg this flight number operates that day. When the flight number operates several legs that day, pass origin (and optionally destination) to pick one; without a selector the default leg is returned and every leg is listed under alternates.

Input Schema

NameRequiredDescriptionDefault
dateYesLocal departure date at the origin airport, YYYY-MM-DD. A flight that leaves at 23:50 and lands the next morning belongs to the day it left. Live records cover a few days back to about two days ahead.
originNoDeparture airport, IATA code (e.g. "IST"; the upstream code such as "ISL" also works). Picks the leg when the flight number operates more than one leg that day.
carrierYesAirline code: the 2-character IATA code (e.g. "TK") or 3-character ICAO code (e.g. "THY"). For flight "TK1848" this is "TK".
refreshNotrue skips FlightByte's cache and asks upstream now (counts as a normal request). Leave unset unless the user needs a guaranteed fresh answer.
flightIdNoExact leg pick: a providerFlightId from a previous response's `alternates`, or a flightId from an error's list of legs.
destinationNoArrival airport, IATA code (e.g. "JFK"). Narrows further when several legs leave the same airport.
flightNumberYesFlight number without the airline code: 1 to 4 digits and an optional letter suffix. For "TK1848" this is "1848". Leading zeros are ignored.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds substantial behavioral context: the returned snapshot structure, branchable status fields, delay/cancellation flags, time representations, cache behavior, and alternate-leg handling.

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?

The description is long but front-loads the most important information: equivalence to get_flight and usage guidance. The detailed return-field enumeration is justified because there is no output schema, though it is dense and could be tightened slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and seven parameters, the description provides the necessary return-value context and leg-selection semantics. Combined with the 100% schema coverage and annotations, an agent has enough information to 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?

Schema coverage is 100%, so the schema already documents parameter formats and meanings. The description adds value beyond the schema by explaining the origin/destination leg-selection behavior and what the default leg and alternates mean when a flight number operates multiple legs.

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 a specific lookup operation and explicitly distinguishes it from get_flight: same data, same parameters, but sent as query parameters to /v1/flights/search. An agent can identify the tool and its relationship to the sibling without opening either schema.

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?

It gives explicit routing guidance: 'Use either one, not both' relative to get_flight. It also explains how to disambiguate multi-leg flight numbers using origin and destination, and what happens when no selector is provided.

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