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

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.