Transit data should be solved.
Buses have routes. Trains have stations. Stations have coordinates. Agencies publish feeds. Phones know where we are. Calendars know where we need to be.
And yet, trying to answer "should I leave now?" still somehow turns into a small systems integration project.
Transit data is a weird category because the data is technically available, but the actual user question is usually not a data question.
I am not asking for a stop ID.
I am asking whether I should put my shoes on.
I am not asking whether an agency supports GTFS.
I am asking whether the transfer at Civic Center is going to ruin my afternoon.
I am not asking for a table of arrivals.
I am asking what I should do next.
That gap is the interesting part.
BART and Muni both expose useful information. Routes, stations, stops, predictions, alerts, schedules, service advisories. If you are willing to work with the data, there is a lot there.
But "the data exists" is not the same thing as "the product is useful."
A normal person is usually not thinking in terms of agencies, feeds, route IDs, stop IDs, prediction endpoints, or service layers. They are thinking in terms of one decision:
Can I leave later?
That question is simple for a human and weirdly complicated for software.
Because the useful answer lives between systems.
BART knows train arrivals.
Muni knows bus predictions.
My phone knows where I am.
My calendar knows where I need to be.
My habits know what routes I actually tolerate.
The hard part is not getting one piece of data.
The hard part is turning all of that into an answer that actually helps me decide what to do next.
Transit APIs expose facts. Good transit products expose judgment.
That does not mean the product needs to be complicated. Actually, it probably means the opposite. The answer should usually be extremely plain:
Leave now.
Wait ten minutes.
Take BART, not Muni.
This transfer is too tight.
You are fine.
You are cooked.
That is the kind of answer I want from transit software.
This is also why MCP is interesting to me.
Not because every transit query needs an AI agent. It does not. Most transit questions should be answered by fast, deterministic software.
But MCP makes it easier to expose small capabilities to an assistant-like layer. Get nearby stations. Check BART departures. Pull Muni predictions. Compare options. Look at my calendar. Consider where I usually go. Return something useful.
Not a giant app.
Not a replacement for maps.
Just a better answer to the question I actually asked.
"Should I leave now?"
That is a tiny question with a lot underneath it.
And that is why transit data still feels weird. We have APIs. We have real-time feeds. We have maps. We have alerts. We have location. We have calendars.
But the product often stops at showing the pieces.
The next step is making the pieces useful at the moment of decision.