Skip to main content
Glama

Start a trip

start_trip

Creates a real Adonde trip in the traveller's account and starts its menu of real tours, sights and food. One destination, or a multi-city route in one call: pass legs (2 to 8 dated stops, as suggest_route's next.start_trip_args gives them). Returns trip_id, the stops (legs, each with its leg_id) and a status. Writes a new trip; nothing is booked. A place we cannot find is refused with a spelling check before anything is created. Use when the place, dates and party are known; use open_trip_form to collect missing details, suggest_route when the cities are not chosen yet. Next, call get_menu one stop at a time.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "destination": "<destination>",
      "start_date": "<start_date>",
      "end_date": "<end_date>",
      "travellers": "<travellers>"
    },
    "name": "start_trip"
  }
}

Input Schema

NameRequiredDescriptionDefault
legsNoMulti-city: the stops in order. Each starts the day the previous one ends (or the next day) and all sit inside start_date to end_date. Send destination and country as the first stop too.
paceNopacked = more per day, balanced = breathing room, loose = an outline.
notesNoAnything else the traveller said that the planner should know.
styleNoTravel style in their words: famous or hidden, early or late, food.
crowdsNoCrowd tolerance: Off the beaten path, Balanced or Big city buzz.
end_atNoRoad trip: where it ends (default: back at start_from).
climateNoThe weather they want, if the place is open.
countryNoCountry name, e.g. Portugal. Send it when known; it keeps same-named cities apart.
end_dateYesLast day of the trip, YYYY-MM-DD (not before start_date). Long trips are fine, up to about six months.
interestsNoShort interest words, e.g. food, museums, hiking.
trip_modeNoThe shape of the trip. standard (default); road = a drive (no flights, stops at most 4 h apart; pass start_from and optionally end_at); weekend = 1 to 3 nights, small menu, loose pace; domestic = inside the traveller's home country, flights limited to domestic airports.
trip_typeNoWhat kind of trip it is, e.g. Relax or Culture deep-dive.
intent_refNoThe reference at the end of a chat line an Adonde card posted, e.g. K7Q2MD from "Code: K7Q2MD." (older cards: "(ref K7Q2MD)"). Pass it on its own: the card's exact arguments load on our side. Add only what the line says is still missing (for a route, the travellers).
start_dateYesFirst day of the trip, YYYY-MM-DD.
start_fromNoRoad trip: where the drive starts.
travellersYesWho is travelling: adults and children's ages.
around_cityNoHow they like to get around each city, e.g. Walk or Metro.
destinationYesCity or town, e.g. Lisbon.
origin_cityNoWhere they fly or travel from, e.g. Charleston.
own_flightsNoTrue when they are booking their own flights, so airfare is left out.
budget_levelNoPrice band: budget, mid or luxury.
dealbreakersNoThings to avoid.
traveling_asNoWho is going: Solo, Couple, Family or Friends group.
wants_to_seeNoThings they want to see or do (the app's 'What you want to see').
between_stopsNoHow they like to get between stops (multi-city): Flight, Train, Bus, Drive, Boat, Hike.
resolved_placesNoSet by the trip form: places the traveller picked from search results, already located. Leave out when calling this yourself.
budget_per_nightNoWhat they want to spend on a stay per night, in the trip currency, if they said.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the write/non-idempotent/open-world profile; the description goes further by disclosing that nothing is booked, that invalid places are rejected with a spelling check before any creation occurs, and what comes back (trip_id, stops with leg_id, status). It stops short of auth, rate-limit, or failure-mode detail beyond the place check.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five sentences ordered as purpose, scope, return shape, write/validation behavior, usage routing, next step. No filler, and the most decision-relevant facts (multi-city in one call, nothing is booked) are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 27-parameter nested-object tool with no output schema, the description supplies the missing pieces: the return shape, the pre-creation validation behavior, the multi-city alternative to a single destination, and the correct next tool. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: multi-city routes go in one call with 2–8 dated stops, and legs should be taken from suggest_route's next.start_trip_args. That cross-tool sourcing hint is not derivable from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Creates a real Adonde trip in the traveller's account') plus the downstream effect (starts its menu of tours, sights and food). It also carves out its scope explicitly against siblings by naming open_trip_form and suggest_route, so an agent can distinguish it without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives both the trigger condition ('use when the place, dates and party are known') and the two alternatives with their own conditions (open_trip_form for missing details, suggest_route when cities aren't chosen). It even sequences the follow-up call ('Next, call get_menu one stop at a time').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources