Plot an AI-planned road trip onto an editable Stopful map — drive times, hotels & EV chargers.
Scored across 1 tool
With only one tool in the set, there is no possibility of selecting the wrong tool. The single tool's purpose (create/update and render a road trip) is unambiguous.
plot_trip follows a clear verb_noun snake_case pattern. With a single tool there is nothing to conflict with, so consistency is trivially satisfied.
A single tool is on the thin side, though it is an unusually capable omnibus that handles creation, updating, geocoding, and rendering in one call. It is borderline rather than a clean fit for the domain.
The tool covers create, update, and render, but there is no way to list existing trips, fetch a trip by id without plotting it, or delete a trip. Agents needing to browse or clean up trips would hit dead ends.
Creates a road trip on Stopful, or updates one plotted earlier, and returns an interactive map of it — adding, removing, reordering or renaming stops, changing nights, dates or party size, and redrawing the route. Renders a multi-stop driving route as an interactive map and returns a link to it, plus an inline map in clients that support one. Takes a list of stops in driving order, each with a place name, optional decimal lat/lon and number of nights; a stop without coordinates is geocoded from its name, and coordinates that fall far from where the name resolves are reported back in the result. Accepts an optional trip name, start date, party size, and a day-by-day itinerary that becomes a day view over the map. The map shows per-leg drive times and distances and an estimate of what the trip will cost before anything is booked, and is editable: the traveller can drag a pin to move a stop or drag the route to add one, and their changes are saved to the trip. Covers road trips and other multi-stop routes; a single destination or a route with no stops to draw has nothing to render. The result contains the map link, the trip as structured data, and the trip's id (see the id parameter for updating an existing trip).
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Id of a trip returned by an earlier call. SEND IT whenever this call is about a trip already plotted in this conversation — showing one of its days, fixing a stop, changing the route. WITHOUT `id` a separate new trip is created and the traveller is left with a pile of near-duplicate maps instead of one they can follow. With it the map link stays the same and their own edits survive. To change an existing trip, send its `id` together with the COMPLETE new `stops` and `days`; there are no partial updates. The map link then stays the same, and edits the traveller made on the map survive. Stops: a re-sent stop keeps the position they dragged it to, stops or waypoints they added on the map but absent from `stops` are kept, and a stop that was there before and is now omitted is removed. Activities: a re-sent one keeps its identity and the place, price and booking it carries on the map, which this tool does not report and so cannot be sent back; an activity the traveller added themselves is kept whether or not it appears here; one this tool showed earlier and now omitted is removed. Without an `id` a separate new trip is created and none of that carries over. Sending `id` with no `stops` is also accepted and changes nothing — it returns the trip exactly as saved. | |
| days | No | The day-by-day itinerary: one entry per calendar day of the trip, in order, each with a title and the day's activities. It renders as a tappable day view over the map, and selecting a day highlights that day's driving; the activities also become the trip's itinerary in the full Stopful planner, where the traveller can edit them. Send it when planning a trip, or when rewriting the itinerary — the day titles replace the saved ones wholesale, there are no partial day updates, while the activities under them are reconciled with what is saved rather than overwritten (see `id`). On a call that only changes the route of an existing trip, leaving `days` out keeps the saved itinerary untouched, which is usually what is wanted; the result echoes whatever is saved either way. | |
| name | No | Optional trip name (e.g. 'Lisbon → Pyrenees'). Defaults to first → last stop. | |
| stops | Yes | The route in driving order, 1 to 40 entries (the first is the origin). Required for a normal call — the only call that omits it is `id` on its own, which re-reads a saved trip unchanged. Each entry needs `name`; every other field is optional. A stop is a place the traveller sleeps, or a place on the road between two such places. An outing made from a base — a waterpark, a market, a cave, a viewpoint visited from the hotel and returned from the same day — is NOT a stop: put it under `days` as that day's activity, and do not repeat the base between outings. Outings sent as stops are moved under their day. | |
| guests | No | Optional party size. | |
| focusDay | No | Optional. Open the map on this day of the itinerary, 1 = the first day. The map shows ONE DAY at a time: the chosen day's stops, activities and driving, with the rest of the route greyed. Use it WITH `id` to answer 'show me day 3' about a trip already plotted — that gives the traveller one map they can page through instead of a new map per day. Omitted, the map opens on the day the trip is actually on (day 1 before it starts), and the traveller can switch day or ask for the whole route from the map itself. | |
| startDate | No | Optional trip start as ISO yyyy-mm-dd. |
| Name | Required | Description |
|---|---|---|
| id | No | The trip's id. Pass it back as the `id` argument to apply a later change to this same trip. |
| url | Yes | Link that opens this trip on the map at stopful.com. |
| days | No | The day-by-day itinerary. Activities may include ones the traveller added in the planner rather than through this tool. |
| trip | Yes | The trip as rendered, after geocoding and (on a continuation) merging the traveller's own map edits. |
| assumed | No | Stops placed from their name alone because no coordinates were given — approximate pins. |
| focusDay | No | Set when the call asked for one day: the map opens on that day of the itinerary, 1 = the first day. |
| notFound | No | Stops that were requested but could not be placed, so they are absent from the map and the route. |
| warnings | No | Stops whose supplied coordinates are far from where their name resolves, with the distance and the resolved position. |
| unchanged | No | True when the call only read the saved trip and changed nothing — an `id` sent with no `stops`. |
| keptByTraveller | No | Stops left where the traveller placed them on the map, so the coordinates supplied in this call were not applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so safety is covered; the description goes well beyond that by disclosing that map edits persist, that the map link stays stable across updates, that geocoding is attempted and coordinate/name mismatches are reported back, and that there are no partial updates for `stops` or `days`. It is consistent with the destructive/non-idempotent annotations rather than contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and primary behavior are front-loaded, and every sentence carries information, but it is a single dense block that partially duplicates the schema (map rendering is described twice, and the id/update semantics are re-explained). Tighter grouping would improve scanability without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex nested-schema tool with an output schema, the description covers the create/update duality, stops-vs-activities placement, editable-map behavior and the no-partial-update rule. Return-value detail is correctly left to the output schema, and 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema itself already explains `id` reconciliation semantics, stop vs activity placement, `nights` conventions and `focusDay` at length. The description largely restates this and even defers ('see the `id` parameter'), so it adds little parameter meaning beyond the structured fields — the baseline 3 for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names the verb and resource precisely — 'Creates a road trip on Stopful, or updates one plotted earlier, and returns an interactive map of it' — and immediately enumerates the mutating operations (adding, removing, reordering, renaming stops). An agent knows exactly what this tool does and what it produces 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit create-vs-update routing (send `id` for an existing trip, omit it for a new one) and an explicit when-NOT clause: 'a single destination or a route with no stops to draw has nothing to render.' It also directs outings away from `stops` and into `days`, which is the main misuse risk for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
plot_trip1 field changedInput schema / properties / focusDay / descriptionPrevious value: -"Optional. Open the map on this day of the itinerary, 1 = the first day. The map has a day view: this selects that day, greys the rest of the route and shows only that day's stops and activities. Use it WITH `id` to answer 'show me day 3' about a trip already plotted — that gives the traveller one map they can page through instead of a new map per day. Omit it for the whole trip."New value: +"Optional. Open the map on this day of the itinerary, 1 = the first day. The map shows ONE DAY at a time: the chosen day's stops, activities and driving, with the rest of the route greyed. Use it WITH `id` to answer 'show me day 3' about a trip already plotted — that gives the traveller one map they can page through instead of a new map per day. Omitted, the map opens on the day the trip is actually on (day 1 before it starts), and the traveller can switch day or ask for the whole route from the map itself."plot_trip3 fields changedInput schema / properties / days / items / properties / items / items / properties / title / descriptionPrevious value: -"The place or activity, e.g. 'Altstadt Salzburg'."New value: +"The place or activity, e.g. 'Altstadt Salzburg'. Every outing from a base belongs here — this is the only place it should appear, never also in `stops`."Input schema / properties / stops / descriptionPrevious value: -"The route in driving order, 1 to 40 entries (the first is the origin). Required for a normal call — the only call that omits it is `id` on its own, which re-reads a saved trip unchanged. Each entry needs `name`; every other field is optional."New value: +"The route in driving order, 1 to 40 entries (the first is the origin). Required for a normal call — the only call that omits it is `id` on its own, which re-reads a saved trip unchanged. Each entry needs `name`; every other field is optional. A stop is a place the traveller sleeps, or a place on the road between two such places. An outing made from a base — a waterpark, a market, a cave, a viewpoint visited from the hotel and returned from the same day — is NOT a stop: put it under `days` as that day's activity, and do not repeat the base between outings. Outings sent as stops are moved under their day."Input schema / properties / stops / items / properties / nights / descriptionPrevious value: -"Optional. Nights at this stop: 0 = pass-through / day stop, 1 or more = overnight. Defaults to 1 when absent."New value: +"Optional. Nights at this stop: 0 = a pass-through on the drive (somewhere the route goes through without staying), 1 or more = overnight. Defaults to 1 when absent. A place visited from a base and returned from is an activity under `days`, not a 0-night stop."Plan trips on a map: routed transport, day-by-day itineraries, and a plan you can share.
Plan U.S. road trips across 104 published drives with reviewed stops and honest detour costs.
Travel planner: create, edit, and explore trip itineraries from your Travolp AI assistant.
Your saved places, trips and travel plans — see them, plan days, and add to them from your AI.
Add one secure layer between your agents and this server.
