Plot an AI-planned road trip onto an editable Stopful map — drive times, hotels & EV chargers.
Scored across 1 tool
With only one tool, there is no chance of selecting between overlapping tools. The single tool is unambiguous by default, even though it handles multiple actions internally.
The single tool name 'plot_trip' follows a verb_noun convention. With only one tool, there is no inconsistency to evaluate, so the naming is trivially consistent.
A single tool is too few for a road trip planner, which would typically need separate operations for fetching, listing, or deleting trips. The one tool is overloaded with create/update responsibilities, making the count mismatched with the apparent scope.
The tool supports creating and updating trips, but lacks dedicated read, list, or delete operations. Agents cannot retrieve existing trips without an ID from a prior call, and there is no way to remove a trip, leaving significant gaps in common workflows.
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?
The description discloses several non-obvious behaviors beyond the annotations: geocoding of stops without coordinates, reporting of coordinate/name mismatches, the editable map with drag-to-move and drag-to-add, per-leg drive times/distances and cost estimates, and the reconciliation semantics for stops and activities when an `id` is sent. It also explains that outings sent as stops are moved under their day. This is rich behavioral context that the annotations (readOnlyHint=false, openWorldHint=true) do not provide.
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?
The description is long, but it earns its length by covering complex create/update semantics, geocoding behavior, map editing, and reconciliation rules. It is front-loaded with the core purpose and output, then expands into parameter-specific guidance. A small deduction because the opening paragraph packs many clauses into a single long sentence, and some redundancy exists between the main description and the `id` parameter description.
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?
Given the tool's complexity (7 parameters, nested objects, create/update duality, reconciliation semantics, output schema present), the description is remarkably complete. It covers what the tool does, when to use it, how parameters interact, what the result contains, and edge cases (no stops, id-only call, day-only updates). The output schema exists, so return values need not be spelled out in the description. Nothing an agent needs to call this 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 coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema. It explains the driving-order semantics of `stops`, the distinction between stops and day activities, the meaning of `nights` (0 = pass-through), the behavior of `id` for updates, the reconciliation rules for days/activities, and the `focusDay` use case. This goes far beyond the schema's field-level descriptions and materially helps an agent construct correct calls.
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 description opens with a specific verb and resource ('Creates a road trip on Stopful, or updates one plotted earlier') and immediately distinguishes the tool's dual create/update role. It names the concrete behaviors (adding/removing/reordering stops, changing nights/dates/party size, redrawing the route) and the output (interactive map link), so an agent knows exactly what this tool does and what it produces.
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 when-to-use guidance: it covers road trips and multi-stop routes, and states that a single destination or a route with no stops has nothing to render. The `id` parameter description goes further, explaining when to send it (updating an existing trip) versus when to omit it (creating a new one), and warns against leaving the traveller with near-duplicate maps. This is strong usage guidance embedded in the description.
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."plot_trip3 fields changedInput schema / properties / focusDayAdded value: +{
+ "description": "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.",
+ "type": "integer"
+}Input schema / properties / id / descriptionPrevious value: -"Optional. Id of a trip returned by an earlier call, identifying which trip this call applies to. 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."New value: +"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."Output schema / properties / focusDayAdded value: +{
+ "description": "Set when the call asked for one day: the map opens on that day of the itinerary, 1 = the first day.",
+ "type": "integer"
+}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.
Plan group trips with your AI: itineraries, checklists, shopping, expenses and who owes whom.
Add one secure layer between your agents and this server.
