TripRescue

What it does

An airline moves your flight. TripRescue lets a traveller—or a browser agent working with them—inspect the affected booking, state recovery constraints such as arrival time, maximum extra cost, and stops, compare ranked alternatives, preview the exact itinerary and price difference, approve the change in the page, and verify the updated booking.

It runs against a real Duffel test-mode order. Duffel's sandbox generates the airline change, the booked airline supplies the change offers, and the app verifies the confirmed order change by refetching it.

Why WebMCP fits

Trip recovery is a high-stakes, multi-step, stateful task where guessing buttons from pixels is unsafe. The agent needs the current booking, must obey explicit limits, must never confirm without the traveller, and must prove the result.

TripRescue registers five focused tools from the top-level page with the imperative document.modelContext.registerTool API:

• get_trip
• find_recovery_options
• preview_trip_change
• apply_trip_change
• get_change_status

The tools use the page's signed session. Booking IDs, provider tokens, and passenger data never enter the prompt. Read, search, preview, apply, and verify remain separate operations with appropriate annotations and compact normalized outputs.

A better human-agent experience

Every tool call updates the visible page before resolving, so the traveller sees the same state the agent is reasoning about. An Agent Activity log records each call and its purpose.

The consequential write is protected by a server-issued preview, order fingerprint, expiry, exact-price revalidation, and single-use idempotent confirmation. Calling apply_trip_change opens an in-page confirmation dialog. The traveller—not the agent—must review the itinerary and explicitly confirm it.

This lets the traveller state intent once—“direct, arrive by 1 PM, no more than $150 extra”—while the agent converts it into a constrained search, ranks valid options, stages the best one, and hands control back exactly when the booking and test charge would change. Success is defined by the refetched provider booking, not merely an HTTP 200.

How it was built

TripRescue uses Next.js 16, TypeScript, Zod, Tailwind CSS v4, the WebMCP imperative API, and the Duffel Flights API in test mode. It is deployed behind nginx with pm2 on Hetzner. GitHub Actions runs lint, typechecking, tests, and a production build before deploying, then verifies the public URL.

Testing

Open the live app in ChatGPT's in-app browser or Chrome with WebMCP enabled. Create a sandbox trip, simulate an airline change, and ask the browser agent to find a nonstop replacement arriving before 1 PM for no more than $150 extra. Preview the best option, apply it, approve the in-page confirmation, and verify the refetched booking.

Honest limitations

Duffel test mode only. Schedules and prices are synthetic, and the airline change is simulated by Duffel. No live bookings or real payments occur. The demo uses the LHR → LTN Duffel Airways scenario supported by Duffel's sandbox.

Built With

• duffel-flights-api
• github-actions
• next.js
• nginx
• pm2
• tailwind-css
• typescript
• vitest
• webmcp
• zod