Skip to main content
Glama
Sign In

Adónde

by com.getadonde
OverviewDiscussionsAdmin

Suggest a route

suggest_route
Read-onlyIdempotent

Suggests where to go and in what order for a country, region or big city. Returns 3 to 7 ordered stops with nights, a one-line why, best months and highlights, getting_there for each hop (distance and train, drive or fly advice), the best time to go, and next.start_trip_args. days counts calendar days, first and last included (7 days is 6 nights). Reads only; creates nothing. Use when the traveller asks where to go, which cities, how to split the days or when to go; then offer start_trip with the route as legs. Use get_city_guide for one city, open_trip_form when the places are settled but details are missing.

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>"
    },
    "name": "suggest_route"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoTrip length in calendar days, when known.
modeNoroad = a drive: every hop is by car, stops are at most max_drive_hours apart, and the card gets a road-trip header.
paceNopacked = more per day, balanced = breathing room, loose = an outline.
monthNoMonth of travel: a number 1 to 12 or a name such as March.
end_atNoRoad trip: where it ends (default: back at start_from).
interestsNoShort interest words, e.g. food, beaches, hiking.
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_dateNoWhen the trip starts, YYYY-MM-DD, if known: next.start_trip_args then carries dated legs.
start_fromNoRoad trip: where the drive starts.
travellersNoWho is travelling: adults and children's ages.
destinationYesCountry, region or big city, e.g. Portugal, Southeast Asia, Tokyo.
max_drive_hoursNoRoad trip: longest drive between stops in hours (default 4).
start_trip_extraNoSet by Adonde's cards: the rest of the trip details (budget, flights, notes), carried unchanged into next.start_trip_args. Leave out when calling this yourself.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, but the description adds substantial behavioral detail. It describes the return shape, including 3 to 7 ordered stops, nights, per-hop getting_there advice, best months, highlights, and next.start_trip_args. It also clarifies the day-counting convention.

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?

The description is front-loaded with purpose and return details, then moves to usage and alternatives. Every sentence contributes to selecting or invoking the tool, and the dense return-field list is justified because there is no output schema.

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 complex route-suggestion tool with 13 parameters and no output schema, the description covers purpose, return shape, day-count semantics, read-only behavior, alternatives, and the handoff to start_trip. The schema already documents the individual parameters thoroughly.

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 description coverage is 100%, so the schema already carries most parameter semantics. The description adds useful meaning beyond the schema for the days parameter by clarifying that days counts calendar days with first and last included, e.g. 7 days is 6 nights.

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?

The description states a specific verb and resource: it suggests where to go and in what order for a country, region, or big city. It also distinguishes the tool from get_city_guide and open_trip_form, so an agent can route requests without opening sibling schemas.

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?

It gives explicit triggers: when the traveller asks where to go, which cities, how to split days, or when to go. It also names alternatives and next steps: get_city_guide for one city, open_trip_form when places are settled, and start_trip with the route as legs.

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

All Adónde toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources