Skip to main content
Glama
Sign In

Adónde

by com.getadonde
OverviewDiscussionsAdmin

Let our AI plan the days

build_trip
Destructive

Lets our AI choose from the same menu under the same rules and place the days, for every stop of the trip. Runs in the background and returns the build status; read progress and the days with get_trip. Writes: fills the days not already placed (fresh true redoes every day) and uses the traveller's AI allowance. Ratings are honoured: love is always included, like when it fits, skip never. Ask once for blocked time before building and pass it. Use when the traveller does not want to pick; use place_picks when they chose items, edit_day or add_stop to change single items afterwards.

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": {
      "trip_id": "<trip_id>"
    },
    "name": "build_trip"
  }
}

Input Schema

NameRequiredDescriptionDefault
freshNoChoose every day again, even days already placed with place_picks (default false: placed days stay as picked).
ratingsNoThe traveller's quick ratings from the menu card, as menu ids: love = must be in the plan, like = included when it fits, skip = never. Saved on the trip, so a later build_trip honours them. Text-only clients: ask which they love, like or want to skip, and pass the ids.
trip_idYesThe trip's id (trip_id), as returned by start_trip or list_trips.
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).
blocked_timeNoTime to keep clear: the traveller's own plans, a wedding, a work call. The builder seats nothing over these windows. Ask 'Any blocked time I should keep clear?' once before building.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that the run is asynchronous and returns only a build status (read progress with get_trip), that it consumes the traveller's AI allowance, and precisely what is written (fills unplaced days, `fresh: true` redoes every day including place_picks picks). It also notes ratings persist on the trip, which is non-obvious state behavior. No contradiction with destructiveHint=true / idempotentHint=false.

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

Conciseness4/5

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

Purpose and the async/return caveat are front-loaded, and nearly every clause carries routing or behavioral information. It is dense and slightly run-on in the middle (ratings rule plus blocked time plus alternatives in one block), but no sentence is purely filler.

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 5-parameter mutation with nested objects and no output schema, the description supplies the missing pieces: that the call is fire-and-forget with a status, where to read results, what gets overwritten, and what the call costs. Nothing an agent needs to invoke it correctly is absent.

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 already 100%, so the baseline is 3, but the description adds genuine meaning: the love/like/skip rule is restated as builder behavior ('love is always included, like when it fits, skip never') and blocked_time gets a concrete elicitation instruction ('Ask once for blocked time before building and pass it'). It does not, however, explain intent_ref or how it interacts with the card-loaded arguments.

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+resource (AI places the days of the trip) plus the scope 'for every stop of the trip', and explicitly contrasts itself with place_picks, edit_day and add_stop. An agent can tell exactly which planning tool this is without opening the 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 the positive trigger ('use when the traveller does not want to pick') and names three alternatives with their own triggers (place_picks when items were chosen, edit_day/add_stop for single-item changes afterwards). It also instructs to ask for blocked time once before building, which is a prerequisite stated up front.

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