Skip to main content
Glama
gavgrego

seats.aero MCP server

by gavgrego
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

License: MPL 2.0

seats.aero MCP server

Not affiliated with seats.aero

A minimal TypeScript MCP server for searching award availability through the seats.aero partner API.

You need a seats.aero Partner API key. Eligible seats.aero Pro users can generate one from their seats.aero settings; usage remains subject to the seats.aero terms and API limits.

Endpoint access

Not every endpoint is available to every Partner API user:

  • live_search cannot be used with a seats.aero Pro API key. It requires a commercial agreement with seats.aero.

  • refresh_cached_data cannot currently be used by commercial users; the API documentation directs commercial users to live_search instead.

The server cannot determine the type of API key locally, so these restrictions are advertised in its MCP instructions, tool descriptions, and tool metadata.

Related MCP server: Flight Search MCP Server

Setup

Requires Node.js 20 or newer.

pnpm install
pnpm build
pnpm start

Set SEATS_API_KEY in your MCP client configuration:

{
  "mcpServers": {
    "seats": {
      "command": "node",
      "args": ["/absolute/path/to/seats-mcp/build/index.js"],
      "env": {
        "SEATS_API_KEY": "YOUR_SEATS_AERO_API_KEY"
      }
    }
  }
}

Tools

Tool

seats.aero endpoint

Access

Purpose

get_flights

Cached Search

Partner API

Search cached availability across airports, dates, cabins, carriers, and mileage programs.

get_bulk_avail

Bulk Availability

Partner API

Retrieve many cached availability objects from one mileage program.

get_routes

Get Routes

Partner API

List routes tracked for one mileage program.

get_destinations

Get Destinations

Partner API

Find airports reachable nonstop from or to one airport and the cheapest raw price per cabin.

get_trips

Get Trips

Partner API

Retrieve flight-level details for an Availability object.

refresh_cached_data

Refresh Cached Data

Pro users; not commercial

Queue or poll refreshes for cached Availability objects.

live_search

Live Search

Commercial agreement only; not Pro

Search a specific route and date live for one mileage program.

Cached search accepts comma-delimited airport lists (SFO,LAX), cabin lists (economy,business), carrier lists (DL,AA), and source lists (aeroplan,united). Dates use YYYY-MM-DD.

Live searches typically take 5-15 seconds. They can fail when an airline is unavailable, so callers should limit retries and use exponential backoff. Prefer get_flights when cached availability is sufficient.

This covers all seven active Partner-Authorization endpoints in the current seats.aero API reference. OAuth consent, token, and user-info endpoints are not exposed as tools because they are application authorization flows rather than award-availability operations; this server authenticates with SEATS_API_KEY.

Development

pnpm test

The tests build the server and exercise request construction with a mocked seats.aero API.

Releases

Releases follow Semantic Versioning and are managed on GitHub by Release Please:

  • fix: commits produce a patch release.

  • feat: commits produce a minor release.

  • commits with a ! after the type or a BREAKING CHANGE: footer produce a major release.

  • docs:, test:, chore:, and other non-user-facing commits do not trigger a release by themselves.

After release-worthy commits land on main, GitHub Actions creates or updates a release PR containing the next version and changelog. Merging that PR creates the corresponding vX.Y.Z Git tag and published GitHub Release. See CONTRIBUTING.md for the complete workflow.

Available Tools

7 tools
get_bulk_availB
Read-onlyIdempotent

Find bulk availability for a particular source.

ParametersJSON Schema
NameRequiredDescriptionDefault
skipNo
takeNoMaximum results to return (10-1000; default 500).
cursorNo
sourceYesMileage program source to retrieve.
endDateNoLatest departure date, in YYYY-MM-DD format.
startDateNoEarliest departure date, in YYYY-MM-DD format.
cabinClassNoOnly return results with this cabin available.
originRegionNoOnly return results originating in this region.
include_filteredNoInclude raw results normally removed by dynamic-price filters.
destinationRegionNoOnly return results arriving in this region.

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, indicating a safe, non-mutating operation. The description adds no behavioral details such as pagination, rate limits, or result completeness, but it also does not contradict the annotations. The annotations carry the transparency burden, so the score is adequate but not enhanced.

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 a single sentence with no redundant words, front-loading the action. However, it is so brief that it verges on under-specification; it could have added useful context while remaining concise.

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

Completeness2/5

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

The tool has 10 parameters, no output schema, and complex sibling tools. The description 'Find bulk availability for a particular source' is too thin to explain what 'bulk availability' means, what the response contains, or how to construct a query. Significant gaps remain for an agent to use the tool 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?

Schema coverage is 80%, with detailed descriptions for most parameters, so the baseline is 3. The description only adds marginal meaning by implying the 'source' parameter is the key filter ('for a particular source'), but it offers no additional syntax or contextual detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Find' and resource 'bulk availability' scoped to 'a particular source,' which helps distinguish it from sibling tools like get_flights or get_destinations. However, it does not clarify what 'bulk availability' means (e.g., multi-date or multi-route results), leaving some ambiguity about the tool's exact function.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like live_search or get_flights. There is no mention of use cases, prerequisites, or exclusions, leaving the agent without context for tool selection.

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

get_destinationsA
Read-onlyIdempotent

Find airports reachable nonstop from or to one airport, with the cheapest raw mileage price per cabin.

ParametersJSON Schema
NameRequiredDescriptionDefault
originAirportNoOrigin airport or metro code. Returns reachable nonstop destinations.
destinationAirportNoDestination airport or metro code. Returns nonstop origin airports.

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly, openWorld, and idempotent hints, so safety is covered. The description adds key behavioral context beyond annotations, such as 'cheapest raw mileage price per cabin' and the directionality of search. However, it does not detail return format or behavior when both params are omitted.

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 a single, well-structured sentence that front-loads the core purpose and includes a meaningful detail. Every word contributes value; there is no redundancy or fluff.

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

Completeness3/5

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

The tool has no output schema, and the description does not explicitly describe the return values or behavior when both optional parameters are provided or omitted. While annotations and schema cover safety and parameter semantics, the description leaves some ambiguity about output structure and edge cases, making it adequate but not 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 description coverage is 100%, with each parameter already having a description. The tool description adds no additional parameter meaning beyond what is in the schema, so the 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 finds airports reachable nonstop from or to one airport, with a specific detail about pricing (cheapest raw mileage price per cabin). This is a specific verb+resource and distinguishes it from sibling tools like get_routes or get_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 implies the tool's use case (finding nonstop destinations/origins with price) but does not explicitly state when to use it over alternatives or mention any exclusions. There is no reference to sibling tools or conditions where this tool should not be used.

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

get_flightsA
Read-onlyIdempotent

Get cached award flights on seats.aero.

ParametersJSON Schema
NameRequiredDescriptionDefault
skipNoNumber of already-retrieved results to skip.
takeNoMaximum results to return (10-1000; default 500).
cabinsNoCabins that must be available, comma-delimited when specifying multiple cabins.
cursorNoOpaque cursor returned by the first page of this search.
endDateNoLatest departure date, in YYYY-MM-DD format.
sourcesNoMileage program sources, comma-delimited when specifying multiple.
carriersNoTwo-character carrier codes, comma-delimited (for example, DL,AA).
order_byNoSet to lowest_mileage to return the cheapest results first.
startDateNoEarliest departure date, in YYYY-MM-DD format.
cabinClassNoDeprecated single-cabin alias for cabins.
minify_tripsNoReturn fewer trip fields when include_trips is enabled.
departureDateNoDeprecated single-date alias. When startDate or endDate is omitted, this value is used for that bound.
include_tripsNoInclude flight-level trip details in each availability result.
originAirportYesOrigin airport codes, comma-delimited when searching multiple airports (for example, SFO,LAX).
include_filteredNoInclude raw results normally removed by dynamic-price filters.
destinationAirportYesDestination airport codes, comma-delimited when searching multiple airports (for example, FRA,LHR).
only_direct_flightsNoOnly return results with a direct flight available.

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds the 'cached' nature, which signals possibly stale data, but gives no further behavioral details such as pagination or data freshness. With annotations present, the incremental context is moderate.

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, front-loaded sentence with zero wasted words. It immediately communicates the core action, and the schema handles all technical detail, so this brevity is appropriate.

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

Completeness2/5

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

This tool has 17 parameters and no output schema, yet the description is only one sentence. It does not explain the return shape, pagination, the meaning of cursor, or how include_trips affects results. The schema covers parameter meaning, but the description leaves the agent without essential behavioral context.

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% (all 17 parameters have meaningful descriptions), and the tool description adds no parameter-level semantics. The baseline of 3 applies because the schema carries the full burden of parameter explanation.

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 ('Get') and resource ('cached award flights') on seats.aero, clearly distinguishing it from sibling tools like live_search (cached vs. live) and get_trips/get_routes (award flights vs. trips/routes).

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?

No explicit when-to-use or when-not-to-use guidance is provided. The word 'cached' implies this tool serves cached data rather than live searches, but it does not name alternatives like live_search or refresh_cached_data. Usage context is only implied.

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

get_routesB
Read-onlyIdempotent

Get routes for a particular source.

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceYesMileage program source to list routes for.

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is established. The description adds no additional behavioral context beyond stating the action, such as return format or side effects. This is adequate for a simple getter but not enriched.

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 a single, direct sentence that front-loads the verb and object. It contains no filler or redundant information, making it optimally concise.

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 one-parameter read-only tool with strong annotations, the description is mostly complete. However, without an output schema, it does not clarify what 'routes' specifically returns (e.g., city pairs, flight numbers) or any limitations, leaving a minor gap. The enum and sibling names provide some disambiguation, so it remains adequate.

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 input schema has 100% description coverage for the single 'source' parameter, including an enum and a clear description ('Mileage program source to list routes for'). The description does not add extra semantic detail, but the schema already provides sufficient meaning, aligning with the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action ('get') and resource ('routes') and specifies the scope ('for a particular source'). It does not explicitly distinguish from sibling tools like get_destinations or get_flights, but the term 'routes' provides some differentiation.

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

Usage Guidelines2/5

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

The description offers no guidance on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions. The implication that it is meant for a specific source is only derived from the parameter definition, not from the description itself.

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

get_tripsA
Read-onlyIdempotent

Get flight-level trip details for a cached Availability object.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesID of an Availability object.
include_filteredNoInclude dynamically-priced trips that are normally filtered out.

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds the 'cached' qualifier but does not explain implications like openWorldHint or what specific trip fields are returned.

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?

One short sentence that gets straight to the point, with no redundant information. It is appropriately concise 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?

With a simple 2-parameter schema, annotations, and sibling context, the description is sufficient for an agent to understand the tool's purpose, though it lacks detail about the output format. Since there is no output schema, a brief mention of the return structure could improve it, but it's not critical.

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 descriptions fully cover both parameters (id and include_filtered), so the description need not add more. It does not explain how include_filtered affects results beyond the schema, so the baseline of 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 uses a specific verb 'Get' and identifies the resource as 'flight-level trip details for a cached Availability object,' clearly distinguishing it from sibling tools like get_flights or get_destinations.

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 the tool is used when you have a cached Availability object ID and need trip-level flight details, but it does not explicitly mention when not to use it or alternative tools for other scenarios.

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

refresh_cached_dataA
Idempotent

Queue or poll refreshes for 1-250 cached Availability objects. This endpoint cannot be used by commercial users; commercial users should use live_search instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
availabilityIdsYesOne to 250 Availability object IDs returned by cached search or bulk availability.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already indicate readOnly=false and idempotent=true, so the agent knows this is a mutating but idempotent operation. The description adds the behavioral trait of 'queue or poll' and highlights the commercial restriction, which goes beyond what annotations convey. It does not detail side effects, but given the annotations, this is sufficient.

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 composed of two concise sentences, with the primary action stated first and the restriction/alternative immediately after. Every word earns its place, and there is no fluff or redundancy.

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?

The tool has a single parameter fully described in the schema, no output schema, and annotations covering safety profile. The description provides the essential context: what it operates on, the quantity limit, and the exclusion for commercial users. This is complete for the tool's simplicity.

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%, and the schema fully documents the availabilityIds parameter with constraints (1-250 items, string format). The description does not add extra semantics beyond restating the count range, so the baseline score of 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's purpose: to queue or poll refreshes for 1-250 cached Availability objects. It uses a specific verb ('queue or poll') and resource ('cached Availability objects'), and it distinguishes itself from siblings by explicitly comparing to live_search.

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?

The description provides explicit usage guidance, stating that commercial users cannot use this endpoint and should use live_search instead. This clearly signals when to use this tool versus an alternative, fulfilling the dimension fully.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 7 tool updatesv1.2.0
    • Changedget_bulk_avail22 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / cabinClass / description
        Added value: +"Only return results with this cabin available."
      • addedInput schema / properties / cursor / maximum
        Added value: +9007199254740991
      • addedInput schema / properties / cursor / minimum
        Added value: +0
      • changedInput schema / properties / cursor / type
        Previous value: -"number"New value: +"integer"
      • addedInput schema / properties / destinationRegion / description
        Added value: +"Only return results arriving in this region."
      • addedInput schema / properties / destinationRegion / enum
        Added value: +[
+  "North America",
+  "South America",
+  "Africa",
+  "Asia",
+  "Europe",
+  "Oceania"
+]
      • addedInput schema / properties / endDate / description
        Added value: +"Latest departure date, in YYYY-MM-DD format."
      • changedInput schema / properties / endDate / pattern
        Previous value: -"^\\d{4}\\-(0[1-9]|1[012])\\-(0[1-9]|[12][0-9]|3[01])$"New value: +"^\\d{4}-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])$"
      • addedInput schema / properties / include_filtered
        Added value: +{
+  "description": "Include raw results normally removed by dynamic-price filters.",
+  "type": "boolean"
+}
      • addedInput schema / properties / originRegion / description
        Added value: +"Only return results originating in this region."
      • addedInput schema / properties / originRegion / enum
        Added value: +[
+  "North America",
+  "South America",
+  "Africa",
+  "Asia",
+  "Europe",
+  "Oceania"
+]
      • addedInput schema / properties / skip / maximum
        Added value: +9007199254740991
      • addedInput schema / properties / skip / minimum
        Added value: +0
      • changedInput schema / properties / skip / type
        Previous value: -"number"New value: +"integer"
      • addedInput schema / properties / source / description
        Added value: +"Mileage program source to retrieve."
      • changedInput schema / properties / source / enum
        Previous value: -[
-  "eurobonus",
-  "virginatlantic",
-  "aeromexico",
-  "american",
-  "delta",
-  "etihad",
-  "united",
-  "emirates",
-  "aeroplan",
-  "alaska",
-  "velocity",
-  "qantas",
-  "connectmiles",
-  "azul",
-  "smiles",
-  "flyingblue",
-  "jetblue",
-  "qatar",
-  "turkish",
-  "singapore",
-  "ethiopian",
-  "saudia"
-]New value: +[
+  "eurobonus",
+  "virginatlantic",
+  "aeromexico",
+  "american",
+  "delta",
+  "etihad",
+  "united",
+  "emirates",
+  "aeroplan",
+  "alaska",
+  "velocity",
+  "qantas",
+  "connectmiles",
+  "azul",
+  "smiles",
+  "flyingblue",
+  "jetblue",
+  "qatar",
+  "turkish",
+  "singapore",
+  "ethiopian",
+  "saudia",
+  "finnair",
+  "lufthansa",
+  "frontier",
+  "spirit"
+]
      • addedInput schema / properties / startDate / description
        Added value: +"Earliest departure date, in YYYY-MM-DD format."
      • changedInput schema / properties / startDate / pattern
        Previous value: -"^\\d{4}\\-(0[1-9]|1[012])\\-(0[1-9]|[12][0-9]|3[01])$"New value: +"^\\d{4}-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])$"
      • addedInput schema / properties / take / description
        Added value: +"Maximum results to return (10-1000; default 500)."
      • changedInput schema / properties / take / type
        Previous value: -"number"New value: +"integer"
    • Addedget_destinations
    • Changedget_flights36 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / cabinClass / description
        Added value: +"Deprecated single-cabin alias for cabins."
      • addedInput schema / properties / cabins
        Added value: +{
+  "description": "Cabins that must be available, comma-delimited when specifying multiple cabins.",
+  "pattern": "^(economy|premium|business|first)(,(economy|premium|business|first))*$",
+  "type": "string"
+}
      • addedInput schema / properties / carriers / description
        Added value: +"Two-character carrier codes, comma-delimited (for example, DL,AA)."
      • removedInput schema / properties / carriers / maxLength
        Removed value: -2
      • removedInput schema / properties / carriers / minLength
        Removed value: -2
      • addedInput schema / properties / carriers / pattern
        Added value: +"^[A-Za-z0-9]{2}(,[A-Za-z0-9]{2})*$"
      • addedInput schema / properties / cursor / description
        Added value: +"Opaque cursor returned by the first page of this search."
      • addedInput schema / properties / cursor / maximum
        Added value: +9007199254740991
      • addedInput schema / properties / cursor / minimum
        Added value: +0
      • changedInput schema / properties / cursor / type
        Previous value: -"number"New value: +"integer"
      • addedInput schema / properties / departureDate / description
        Added value: +"Deprecated single-date alias. When startDate or endDate is omitted, this value is used for that bound."
      • addedInput schema / properties / departureDate / pattern
        Added value: +"^\\d{4}-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])$"
      • addedInput schema / properties / destinationAirport / description
        Added value: +"Destination airport codes, comma-delimited when searching multiple airports (for example, FRA,LHR)."
      • addedInput schema / properties / destinationAirport / pattern
        Added value: +"^[A-Za-z]{3}(,[A-Za-z]{3})*$"
      • addedInput schema / properties / endDate / description
        Added value: +"Latest departure date, in YYYY-MM-DD format."
      • changedInput schema / properties / endDate / pattern
        Previous value: -"^\\d{4}\\-(0[1-9]|1[012])\\-(0[1-9]|[12][0-9]|3[01])$"New value: +"^\\d{4}-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])$"
      • addedInput schema / properties / include_filtered
        Added value: +{
+  "description": "Include raw results normally removed by dynamic-price filters.",
+  "type": "boolean"
+}
      • addedInput schema / properties / include_trips / description
        Added value: +"Include flight-level trip details in each availability result."
      • addedInput schema / properties / minify_trips
        Added value: +{
+  "description": "Return fewer trip fields when include_trips is enabled.",
+  "type": "boolean"
+}
      • addedInput schema / properties / only_direct_flights / description
        Added value: +"Only return results with a direct flight available."
      • addedInput schema / properties / order_by / const
        Added value: +"lowest_mileage"
      • addedInput schema / properties / order_by / description
        Added value: +"Set to lowest_mileage to return the cheapest results first."
      • removedInput schema / properties / order_by / enum
        Removed value: -[
-  "",
-  "lowest_mileage"
-]
      • addedInput schema / properties / originAirport / description
        Added value: +"Origin airport codes, comma-delimited when searching multiple airports (for example, SFO,LAX)."
      • addedInput schema / properties / originAirport / pattern
        Added value: +"^[A-Za-z]{3}(,[A-Za-z]{3})*$"
      • addedInput schema / properties / skip / description
        Added value: +"Number of already-retrieved results to skip."
      • addedInput schema / properties / skip / maximum
        Added value: +9007199254740991
      • addedInput schema / properties / skip / minimum
        Added value: +0
      • changedInput schema / properties / skip / type
        Previous value: -"number"New value: +"integer"
      • addedInput schema / properties / sources
        Added value: +{
+  "description": "Mileage program sources, comma-delimited when specifying multiple.",
+  "type": "string"
+}
      • addedInput schema / properties / startDate / description
        Added value: +"Earliest departure date, in YYYY-MM-DD format."
      • changedInput schema / properties / startDate / pattern
        Previous value: -"^\\d{4}\\-(0[1-9]|1[012])\\-(0[1-9]|[12][0-9]|3[01])$"New value: +"^\\d{4}-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])$"
      • addedInput schema / properties / take / description
        Added value: +"Maximum results to return (10-1000; default 500)."
      • changedInput schema / properties / take / type
        Previous value: -"number"New value: +"integer"
    • Changedget_routes4 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / source / description
        Added value: +"Mileage program source to list routes for."
      • changedInput schema / properties / source / enum
        Previous value: -[
-  "eurobonus",
-  "virginatlantic",
-  "aeromexico",
-  "american",
-  "delta",
-  "etihad",
-  "united",
-  "emirates",
-  "aeroplan",
-  "alaska",
-  "velocity",
-  "qantas",
-  "connectmiles",
-  "azul",
-  "smiles",
-  "flyingblue",
-  "jetblue",
-  "qatar",
-  "turkish",
-  "singapore",
-  "ethiopian",
-  "saudia"
-]New value: +[
+  "eurobonus",
+  "virginatlantic",
+  "aeromexico",
+  "american",
+  "delta",
+  "etihad",
+  "united",
+  "emirates",
+  "aeroplan",
+  "alaska",
+  "velocity",
+  "qantas",
+  "connectmiles",
+  "azul",
+  "smiles",
+  "flyingblue",
+  "jetblue",
+  "qatar",
+  "turkish",
+  "singapore",
+  "ethiopian",
+  "saudia",
+  "finnair",
+  "lufthansa",
+  "frontier",
+  "spirit"
+]
    • Addedget_trips
    • Addedlive_search
    • Addedrefresh_cached_data
  2. 3 tool updatesv1.0.0
    • First observedget_bulk_avail
    • First observedget_flights
    • First observedget_routes
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 7 tools

Disambiguation3/5

The tool names and descriptions suggest overlapping purposes: get_destinations, get_routes, get_flights, get_trips, and get_bulk_avail all appear to return availability data at different granularities, but the distinctions are not always obvious. An agent might struggle to choose between get_routes and get_destinations, or get_flights and get_trips, without deeper documentation.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (get_destinations, get_trips, refresh_cached_data, live_search, get_flights, get_bulk_avail, get_routes). The verbs and nouns are clear and predictable, providing a consistent naming convention across the set.

Tool Count5/5

With 7 tools, the server is well-scoped for an award travel search domain. Each tool covers a distinct aspect of querying or managing availability data, and the number is neither excessive nor insufficient.

Completeness4/5

The tool surface covers the main workflows: finding destinations, routes, flights, bulk availability, live search, and refreshing cached data. A minor gap exists in that there is no explicit tool for detailed pricing per flight or for managing specific search parameters, but agents can likely work around this with the available tools.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers