MCP Server

The Seats.aero Model Context Protocol (MCP) server is for AI apps and assistants. It uses Streamable HTTP at https://seats.aero/mcp; add that URL as a remote MCP server in your AI app. The interactive setup guide has instructions for common assistants.

For other apps, use Login with Seats.aero and its OAuth Apps flow instead. MCP connections are separate: creating an OAuth App in the Apps tab does not register an MCP client, and its credentials do not work with MCP OAuth.

Public AI tools can search award flights and reference data without a Seats.aero account. Public flight results cover departures from today through 60 days ahead, and anonymous requests have an IP-based daily limit. Connect an eligible Pro account for account tools, full search access, live searches, and alert management. Authenticated tool calls share the account's daily Pro API quota. You do not need a Partner API key to use MCP.

Supported clients and callbacks

Seats.aero accepts local MCP clients, including Claude Code, with http or https loopback callbacks on 127.0.0.1, [::1], or localhost. A local client can use a different port during authorization if its scheme, host, and path match the registered callback.

The production callback allowlist also supports Claude, ChatGPT, Gemini, Cursor, Perplexity, n8n, Meta Muse, Antigravity, Devin, Mistral Studio, Cloudflare MCP portals, and Microsoft Copilot Studio. These clients use exact, native-app, or tightly constrained hosted callback formats. Arbitrary hosted callback URLs are not accepted. If registration returns invalid_redirect_uri, send the exact callback URL and client platform to [email protected].

MCP OAuth endpoints

Seats.aero's MCP server uses OAuth authorization code with PKCE S256 for public clients. It does not issue client secrets.

Clients should discover the current endpoints and scopes from the metadata URLs. Use https://seats.aero/mcp as the OAuth resource parameter for the main server. Access tokens are bound to that resource.

Register and connect

Clients that use DCR send JSON to the registration endpoint. For example, a local client can register with:

{
  "client_name": "Example desktop assistant",
  "redirect_uris": ["http://127.0.0.1:8765/callback"],
  "token_endpoint_auth_method": "none",
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"]
}

Registration returns a client_id; it does not grant account access. token_endpoint_auth_method must be none, and the request can include one to six approved callbacks. authorization_code is required; include refresh_token to receive a refresh token. The optional scope is a space-separated set of MCP permissions. If omitted, it defaults to the main server's full permission set. Registration is rate limited per IP.

To connect an account, the client sends the user to the authorization endpoint with its client_id, an allowed redirect_uri, response_type=code, scope, resource, state, and a PKCE S256 challenge. The user signs in and approves the requested permissions. The client then exchanges the code and PKCE verifier at the token endpoint using application/x-www-form-urlencoded and sends the access token to MCP as Authorization: Bearer <access_token>. Access tokens expire after 10 minutes; clients that requested refresh tokens must store each replacement refresh token because they rotate.

You can review and disconnect assistants at Seats.aero MCP connections. Disconnecting revokes that connection's tokens. A normal Seats.aero website session cookie does not authenticate MCP requests.