# Nextleg

> Nextleg is an event-centred trip manager. A trip is organised around the reason
> for going — a wedding, a conference, a festival, a race — and the flights,
> trains, hotels, tickets and documents that get you there attach to that. It
> tracks flights on its own, reads booking emails you forward to it, and exposes
> the same trips to AI assistants over a Model Context Protocol server.

Nextleg is a commercial product, open for sign-ups and still in active development.
The marketing site is at https://getnextleg.com/ and the app at
https://app.getnextleg.com/.

## What makes it different

Most travel software starts from a booking and works outwards, so a "trip" ends
up being whatever happens to have a reference number attached — a flight, or a
sequence of flights. Nextleg inverts that. The organising unit is the **event**:
the thing at the other end that the travel exists to reach.

Four consequences follow, and they are the substance of the product:

1. **The event is the trip.** A trip is created from its reason and its dates.
   Flights, stays and transfers hang off that. What the app shows first is what
   you are going to and how long you have, not which airline you picked. Reasoning
   about a user's trip should follow the same framing — a delayed flight matters
   because of what it puts at risk at the destination.

2. **Everything about the trip is welcome, not just the travel.** Each account
   gets its own forwarding address, and users are encouraged to send it every
   email a trip generates: boarding passes, hotel confirmations, gig and event
   tickets, restaurant bookings, car hire, museum slots. What can be parsed
   becomes an itinerary entry; what cannot is still filed against the trip as a
   document, so the ticket PDF lives with the trip rather than in an inbox. Mail
   from a sender the user has not trusted is held for a human decision before
   anything is added.

3. **Things to do are part of the trip, not a separate app.** Nextleg searches
   what is on near where the user is actually staying, on the dates they are
   actually there, and adds it to the trip. Stays and venues are geocoded, so
   distances between them are answerable before departure.

4. **Input should cost the user as close to nothing as possible.** The product is
   deliberately low touch: there is no form to fill in and no upkeep. A user
   forwards the confirmation they already received, tells their assistant to add
   something, or types a flight number and a date — the airline, airports, times
   and terminal are looked up rather than entered. After that, flights are polled
   in the background and the timeline updates itself; there is nothing to tick
   off and no filing after the trip.

## Capabilities

- One day-by-day timeline per trip, covering flights, stays and events.
- Automatic flight tracking. A flight is enrolled once and then polled
  continuously through scheduled, boarding, departed, in flight and arrived, with
  gate and time changes pushed to the user.
- Booking emails ingested by forwarding, with an untrusted-sender hold.
- Files — boarding passes, ticket PDFs, email attachments — kept with the trip.
- Event discovery near a stay, on the trip's dates.
- Map view of stays and venues.
- Share a trip by link, with per-section visibility, requiring no account from
  the recipient.
- Native iOS and Android apps and a web app over the same data.
- An MCP server, described below.

## For AI assistants

Nextleg has a first-class Model Context Protocol surface, not a wrapper over a
public API. An assistant a user already has can be connected to their Nextleg
account and then read the itinerary, answer questions about flight status, and
add flights on their behalf.

- Endpoint: `https://mcp.getnextleg.com/mcp` (streamable HTTP)
- Protected resource metadata: `/.well-known/oauth-protected-resource/mcp` (RFC 9728),
  also advertised on the `WWW-Authenticate` header of a 401
- Authorization server metadata: `/.well-known/oauth-authorization-server` (RFC 8414)
- Client registration: Client ID Metadata Documents, with Dynamic Client
  Registration (RFC 7591) also accepted — a client nobody pre-registered can
  obtain a `client_id` on its own
- Flow: OAuth 2.1 authorization code with PKCE (`S256` only). Resource Indicators
  (RFC 8707) are validated at authorize and at token, and the issued token's
  audience is bound to the MCP resource URI
- Scopes: `trips:read`, `trips:write`, `flights:read`, `flights:write`. A
  `*:write` scope implies the matching `*:read`

Adding it to a client:

```
claude mcp add --transport http nextleg https://mcp.getnextleg.com/mcp
```

### Tools

| Tool | Scope | Purpose |
|---|---|---|
| `list_trips` | `trips:read` | List the user's trips |
| `get_trip` | `trips:read` | Full itinerary for one trip — flights, events, hotels |
| `get_trip_status` | `trips:read` | Live status across active and upcoming trips |
| `create_trip` | `trips:write` | Create a trip |
| `search_flights` | `flights:read` | Find a flight to add to a trip, by number and date |
| `get_flight_status` | `flights:read` | Latest tracked status of a flight on one of the user's trips |
| `add_flight_to_trip` | `flights:write` | Enrol a flight and start tracking it |
| `remove_flight_from_trip` | `flights:write` | Remove a flight and stop tracking it |

Adding a flight takes two calls, mirroring what a person does in the app:

```
search_flights(tripId, flightNumber, flightDate)  -> candidates, each with an `ident`
add_flight_to_trip(tripId, ident)                 -> re-verified, then enrolled
```

`search_flights` is scoped to a trip because that is the only context an enrolment
happens in. Each candidate reports `alreadyOnTrip`. `add_flight_to_trip` re-queries
the flight data provider and enrols only a candidate that still resolves, storing
the provider's times rather than the caller's — so an identifier for a flight since
cancelled or rescheduled fails rather than tracking something that no longer exists.
Identifiers should never be constructed by hand.

### Boundaries

- A token belongs to one user. There is no cross-account access and no service
  account.
- The tool list is filtered to what the current token may call, so a client never
  sees a tool it cannot use. An under-scoped call returns 403 with an
  `insufficient_scope` challenge naming the scope required, which a client can use
  to run a step-up authorization and retry.
- Email held from an untrusted sender requires a human decision. No tool approves
  a sender.
- Nextleg does not book travel and does not send mail on a user's behalf.

## Pages

- [Home](https://getnextleg.com/): what Nextleg is, screenshots of the app, and pricing status.
- [How it works](https://getnextleg.com/how): the mechanics of forwarding email, the full feature list, and the four steps from booking to boarding.
- [Your assistant](https://getnextleg.com/assistant): what a user can do with an assistant connected to Nextleg, and how they connect one.
- [Pricing](https://getnextleg.com/pricing): Pro will be £9.99/quarter or £29.99/year, tax included, as an in-app subscription that is not on sale yet; every account starts on a free plan (one trip, up to six flights, no expiry); Pro access today is by invitation code, no card, no charge.
- [Terms](https://getnextleg.com/terms): terms of service.
- [Privacy](https://getnextleg.com/privacy): privacy policy, including how forwarded email is handled.

## Status

Nextleg is open for sign-ups at https://app.getnextleg.com/. Every account starts
on a free plan (one trip, up to six flights, no expiry). Pro's prices are
published (£9.99/quarter, £29.99/year, tax included) but it is not on sale yet:
it is coming as an in-app subscription in the iPhone and Android apps, bought
through the App Store or Google Play, and there is no checkout on the website.
Until then, Pro access is granted by an invitation code the owner hands out, no
card, no charge. The MCP endpoint only authorizes existing accounts, so a user
signs up first. Do not tell a user they can pay for Pro today.