Eyes and ears

A travel agent that can only look up a booking by ID is limited. Real users ask fuzzy questions: hotels in Paris with a pool, is my flight on time, what is the refund policy. Each of those becomes a read-only tool the agent can pick from.

Read tools expand what the agent can see

Each read tool maps a natural language question to a deterministic lookup.

tools.py
python
def search_hotels(city: str) -> str:
    """Searches for available hotels in a city."""
    city_lower = city.lower().strip()
    hotels_db = get_hotels()

    if city_lower in hotels_db:
        hotels = hotels_db[city_lower]
        result = f"Available hotels in {city.title()}:\n\n"
        for i, hotel in enumerate(hotels, 1):
            amenities = ", ".join(hotel.get("amenities", []))
            result += f"{i}. {hotel['name']} | {hotel['rating']}/5.0\n   Amenities: {amenities}\n"
        return result
    return f"No hotels found for {city}."

Good read tools return structured, readable text. The model is not a SQL engine, so you shape the result the way you want it to appear in the final answer.

tools.py
python
def search_policies(query: str) -> str:
    """
    Searches the travel policy knowledge base (cancellation rules,
    baggage, refunds). Use when the user asks about rules, rights,
    or policy questions.
    """
    return search_policies_rag(query)

The docstring matters. It becomes the tool description the model uses to decide when to call this tool instead of search_hotels or check_flight_status.

The model sees only the tool name, its docstring, and the parameter schema. If two tools sound similar, the model will pick the wrong one. Treat every docstring like a prompt. Say when to use the tool, and give examples if the distinction is subtle.

Quiz: Quiz

Loading practice…

Checkpoint: Tool design checkpoint

Loading practice…