Andiamo: a travel comparison tool with no screen

Looptra's role

Product, data aggregation, operation

Status

In production

Field

Travelers, inside ChatGPT and Claude

Stack

MCP server, rail, coach, air, GTFS timetables

The interface is documentation

There is no button to move, no label to fix after a user test. What the user sees depends on what a language model understood from our tool descriptions, then chose to rephrase. The technical text is no longer an appendix: it is the product.

Door to door, or nothing

A train time that ignores the forty minutes to reach the station and the twenty kilometers at the other end does not answer the question asked. So we have to chain an access leg, a buffer, a long-distance leg and a final leg, out of sources that know nothing of each other.

Every answer has a variable cost

Rail timetables come from open data, air goes through a paid API. An assistant exploring freely can fire off ten searches where the user expected one. The cost of a conversation cannot be predicted in advance: it has to be bounded inside the product.

The route is composed on our side, not in the assistant

Why: exposing only "search trains" and "search coaches" leaves the model to stitch the pieces back together, and it forgets the trip to the station, the buffer, the last mile. A single tool resolves both locations, queries the modes in parallel and returns strategies that are already comparable, each with its score broken down.

What it costs: a heavy tool, slower than a simple call, whose business logic only we can keep up to date.

One score across modes that have nothing in common

Why: time, price, connection risk and comfort are brought down to one shared score, with an explicit trade-off depending on whether you want the fastest or the cheapest. Without that, the answer is a list, and a list is not a recommendation.

What it costs: trade-offs we own publicly, including when a free train ranks behind a paid coach. The score is therefore shown broken down rather than hidden.

Uncertain data has to flag itself

Why: the last leg is either a published timetable or an assumption, when no service reaches the destination after that train. The answer carries the status of the data, and explicitly asks the assistant to tell the traveler. A model reading an unlabeled number will present it as a certainty.

What it costs: answers less clear-cut than those of a comparison site that asserts everything. We prefer an "estimated arrival, to be checked" over an invented coach.

The car is priced, but out of the ranking

Why: time without traffic, distance, fuel at the day's posted price, tolls where a schedule covers them. It is the benchmark the traveler has in mind anyway. Putting it in the ranking would mean recommending a trip we cannot book; leaving it out would mean leaving the question unanswered.

What it costs: a separate class of result, which has to be spelled out in the tool description so the model does not rank it with the others.

What has to last leaves the conversation

Why: seats at 0 € appear and vanish, and a conversation does not last three weeks. Watches, alerts and the traveler profile therefore live server side, on an account, with a dashboard and email capped at one every six hours.

What it costs: an account to create and a personal address to set up before the first use, where everything else works with nothing at all. That is the friction we pay so the expensive features stay bounded per user.