Open Transfer Times

Open Transfer Times

Is this flight connection comfortable, tight, or risky? Open, cited airport transfer data, an engine that explains its verdict, and an MCP server so AI agents can check connections before recommending a flight.

Try it

Ask an AI agent to compare layovers. With the MCP server connected, it gets:

1. IST 3 h BER–IST–PVG: comfortable, margin 135 min, protected itinerary, medium confidence
2. VIE 2 h BER–VIE–PVG: comfortable, margin 65 min, protected itinerary, low confidence
3. FRA 50 min BER–FRA–PVG: risky, margin -5 min, protected itinerary, medium confidence

Each result lists the transfer steps it counted, a confidence level, and the official sources behind the airport data:

BER–LHR–PVG: REASONABLE — A practical connection on one ticket.
Confidence: MEDIUM — The transfer-step durations are rule-of-thumb estimates, not sourced figures.
Layover 90 min, transfer steps 55 min, margin 35 min.
Steps counted: Move through airport 40 min (heuristic); Allow for another security check 15 min (heuristic). No other steps were counted.

With Claude Desktop or any MCP client

Add to claude_desktop_config.json, then fully restart Claude:

{
  "mcpServers": {
    "open-transfer-times": { "command": "npx", "args": ["-y", "open-transfer-times-mcp"] }
  }
}

Then ask, in a new chat: "From Berlin to Shanghai, which is safest: 50 minutes in Frankfurt, 3 hours in Istanbul or 2 hours in Vienna?"

The server is also listed in the official MCP Registry and on Glama. Tools and options: packages/mcp.

From code

npm install open-transfer-times

const { assessConnection } = require("open-transfer-times");

const result = assessConnection(
  { segments: [
    { origin: "BER", destination: "LHR", arrivalTime: "2026-09-20T10:00" },
    { origin: "LHR", destination: "PVG", departureTime: "2026-09-20T11:30" }
  ] },
  { ticketStatus: "protected" }
);
result.quality;          // "reasonable"
result.confidence.level; // "medium"

API reference: packages/core.

Why this exists

Airlines and booking systems decide whether a connection is feasible using minimum connection times (MCT): commercial data sold by IATA and schedule providers. Open flight-search tools can find itineraries but cannot say whether a layover is realistic. This project collects what airports and airlines publish openly, cites every fact, and marks every estimate as an estimate.

How it works

The engine is deterministic: the model that calls it explains the result but never does the arithmetic.

1. Start from the scheduled layover.
2. Deduct the transfer steps that apply at the connection airport: a base transfer allowance, Schengen passport control when the transfer crosses the Schengen border, a terminal change when known, security re-screening, and bag re-check when stated.
3. Rate the remaining margin: comfortable (≥ 45 min), reasonable (≥ 25), tight (≥ 5) or risky.

Two things are reported separately from the rating:

• Confidence (high / medium / low). An airport without a profile, or a route whose border situation is unknown, is always low confidence, so missing data is never presented as "no risk".
• Ticket protection. Separate tickets change the warning and verdict, but do not add transfer time by themselves.

Airport data

13 hub airports have their own profile in airports/, one YAML file each; every other airport uses a standard baseline. All 13 cite official airport or airline pages. Facts confirm transfer steps, for example that Heathrow, Hong Kong, Changi, Incheon, Narita and Doha screen transfer passengers again, while most durations are still estimates (basis: heuristic). COVERAGE.md shows how well each airport is sourced.

Contributions welcome, no code needed. Add an airport, replace an estimate with a sourced figure, or report a rule the format can't express: see CONTRIBUTING.md or open an issue with the Airport data form.

Limitations

• Not an official MCT table, and no delay prediction. It is a structural estimate with its sources attached.
• Durations are mostly rule-of-thumb. No minute value is sourced yet, so no result reaches high confidence.
• One stop at a time. Itineraries with more connections are rejected; check each connection separately.
• Schengen status is known for about 56 airports. A connection at any other airport, or at a Schengen airport to or from one, is reported as low confidence.
• One rule set per airport. Rules that depend on where you arrive from (security at AMS), on terminal pairs (NRT) or on "some cases" (MUC) are not modelled yet.
• Self-transfers. Re-checking bags adds a fixed allowance, but entering and leaving the country is not counted outside Schengen.
• Local clock times. Layovers spanning a daylight-saving change are off by an hour.
• Visa and transit-visa requirements are not covered.

Roadmap

RFC 0001 proposes v0.2: a country for every airport, rules with conditions, self-transfer border steps, time zones, and sourced durations for MUC, NRT and LHR. It addresses most of the limitations above. Feedback is welcome on its discussion issue.

The agent evaluation measures how reliably an AI agent uses the server: 36 questions in Chinese and English, graded on tool calls and answer accuracy.

Repository layout

Development

Requires Node.js 20+.

npm install
npm run check   # airport data validation, lint, all tests, extension build
npm run smoke   # pack both npm packages, install them, call the MCP server
npm run eval    # agent evaluation; needs ANTHROPIC_API_KEY (see eval/README.md)

npm run airports:build regenerates the engine's data after editing airports/*.yaml. CI runs check and smoke on Ubuntu and Windows with Node 20 and 22. Working on the extension: extension/README.md. Changes by release: CHANGELOG.md.

License

MIT. Airport names come from the public-domain OurAirports dataset.