In a real travel app, the data around travel options, hotels, activities etc that are available would be fetched by the LLM from some databases using tools. The data that is shown in the UI should be nearly all be derived from this accurate database information, rather than being written by the LLM based on general knowledge from it's training data. Currently, our demo just relies on hallucination to invent travel itineraries etc.

We should change this to rely on fake data coming from tool definitions, because this will be make our demo far more representative of a real app. We need to show that we can create a compelling, performant, hallucination-free experience using data sources.

For now, the tools can be defined locally in Dart code and just return canned data. This should work great because it avoids dependencies on any real backends, and it allows us to demonstrate that the LLM can process and display data from a tool. When a real app hooks up a real database, we can expect things to work similarly. Also, the fact that the tools are running on the client side doesn't matter because it's ultimately the same LLM and the same kind of inputs/outputs.

So my proposal is to define a tool something like "hotel search" which accepts parameters like date, location, budget, number of people etc, and then returns a list of hotel_result, where each result has some information like hotel name, image(s), cost, location, description etc. We can just hardcode ~20 results for now.

After we create one tool, we can get gemini-cli to create more pretty easily I expect.