The Screenshot That Planned a Wedding Trip

One of my best friends is getting married this summer. Mountain wedding in Colorado. Ceremony at the top of a chairlift. I’m in the wedding party. My girlfriend is flying with me. My parents are flying in from a different city, and they could leave from either of two airports depending on where they happen to be that week.

So there’s a lot to coordinate.

Yesterday I clicked through the RSVP, took a screenshot of the confirmation page, and dropped it in Inbox/ on my Obsidian vault. Then I went to bed.

This morning my system had the whole trip figured out, including the part I didn’t ask for: where everyone meets up.

The morning chain

Every day at 5am a cron runs on my desktop. It scans the inbox folder for anything new and triages.

The screenshot had a Zola URL on it. The agent pulled the URL out of the image, fetched the page, and read it. Couple’s names. Date. Venue at the top of a chairlift. Required waiver. Travel notes for out-of-town guests.

That was enough to anchor a trip note. The note had three attendees from three cities and one drop-dead time: rehearsal dinner at 5 PM Mountain Time on Friday. The drive from Denver International to the venue is 109 miles, about 2 hours and 6 minutes. So everyone’s wheels need to be down at DEN by 1 PM MT to make dinner with a real buffer.

That’s three flight searches. Three fare matrices. One overlap calculation.

And here’s the upgrade from yesterday: the system now talks to Google Flights directly, not airline schedule pages. Real fares. Real flight numbers. Real dates.

The MCP that did the work

There’s an open-source Python project called fli that reverse-engineers Google Flights and exposes it as an MCP server. I installed it this morning:

pipx install flights
fli flights AUS DEN 2026-07-10 --stops 0 --time 5-14 --sort DEPARTURE_TIME

That’s the entire research step from the agent’s perspective. Origin, destination, date, a time window, a constraint. Sub-second response.

I ran it for all three origins. Here’s what came back.

What Google Flights actually showed for Friday July 10, 2026

Austin → Denver (me + Haley)

12 nonstop options. 4 carriers. Times in Mountain Time so I can compare apples to apples.

Raleigh-Durham → Denver (parents, Option A)

Three nonstop options for that day.

Savannah → Denver (parents, Option B)

This is the route the system flagged as “messy.” There are 115 itineraries on Google Flights for that date because almost everything connects. Filtering to “arrive DEN before 1 PM MT” cuts it to 36. Sorting by price gives one clean answer:

So if parents fly Savannah, it’s the Delta one-stop through Atlanta. Anything else is two stops and not worth the savings.

The overlap window — interactive timeline

Three rows, one per origin. Each marker is a real Friday flight arrival at DEN. The green band is the meet-up window. The red band is the deadline.

The cluster between 9 AM and noon Mountain Time is the rendezvous window. The red band on the right is everything that arrives after the 1 PM cutoff and won’t make rehearsal dinner with a buffer. Hover any dot for the flight number, time, and price.

Static fallback (for RSS, plain text readers):

The solutions

After filtering 130+ flight options across three origins down to what arrives by 1 PM MT, lands inside the rendezvous window, and minimizes total cost — three viable combinations remain.

✅ Solution A — Cheapest if parents are home in Raleigh

Brett waits 57 minutes at DEN. Everyone in the rental car by 10:45.

✅ Solution B — Cheapest if parents are in Savannah that week

Parents wait 46 minutes at DEN. Saves $190 over Solution A.

✅ Solution C — Budget hero (Frontier red-eye)

Brett waits ~2.5 hrs at DEN. $170 cheaper than A, but the early Austin departure (4:30 AM Lyft) hurts.

Locked-in pick: Solution A or B, depending on where parents start the week. Confirming with them resolves it.

How the chain actually works

Nothing exotic. The pieces are connected end-to-end:

Inbox/screenshot.png
   ↓ (morning cron, 5am)
URL extraction → Zola scrape
   ↓
Trip note created (location, date, deadline derived)
   ↓
Three parallel fli queries (AUS-DEN, RDU-DEN, SAV-DEN)
   ↓
Filter: arrive DEN ≤ 13:00 MT (rehearsal dinner deadline)
   ↓
Cross-reference arrival times → overlap window
   ↓
Pick cheapest combo per origin that lands in window
   ↓
Render visual band, write to trip note
   ↓
Create 6 Google Tasks with rich descriptions

The piece I added today was the third box. Yesterday the agent was working from typical schedule data scraped off airline route pages. Today it’s hitting Google Flights directly through fli, so the data has actual flight numbers and actual fares for the actual date.

That changes the output from “here are the flights that probably exist” to “Frontier 1815 at $69, here’s the booking link.”

The honest part

I still have to actually book. The MCP doesn’t have purchase capability and shouldn’t. What it gives me is decisions pre-made. I’m not opening seven tabs and trying to mentally cross-reference three sets of arrival times against a 2 PM cutoff and a rendezvous goal.

The system also can’t know things I haven’t told it. It assumed the rehearsal dinner is 5 PM Friday because that’s typical. It might be wrong. It flagged that as an open question for me to confirm with the groom. The fix isn’t to make the AI smarter, it’s to make sure I’m reading the open questions section instead of skimming past it.

The shape of this

A year ago I would have spent two hours on this. Open the Zola page. Switch to Google Flights three times. Switch to Google Maps. Switch to Airbnb. Try to remember which tab had the rehearsal dinner time. Open Google Tasks. Type a task. Forget the next one because I lost the thread.

That’s the actual work of trip planning. Not the decisions. The context-switching.

What the morning agent does is collapse the context-switching into one readable document. The decisions are still mine: which combo to book, whether to fly Thursday night for safety or Friday morning for cost, whether to pay $190 more for the United nonstop from RDU. But the lookup work is done. The connections between the lookups are made. The rendezvous geometry is solved.

The screenshot was the only thing I had to do.

Sources:

• fli — Google Flights MCP and Python library
• Zola wedding page
• DEN to Granby driving time

Flight data pulled live from Google Flights via fli on 2026-04-29 for departure date 2026-07-10. Prices and availability change. Flight numbers were real at time of writing.