Plot an AI-planned road trip onto an editable Stopful map — drive times, hotels & EV chargers.
With only one tool, there is no possibility of confusing it with another tool. The tool's purpose is clearly scoped to plotting and updating road trips.
The single tool name 'plot_trip' follows a clear verb_noun convention, and there are no other tool names to create inconsistency. The pattern is clean and predictable, though there is limited evidence from just one name.
One tool is borderline for a road-trip planner. The tool is broad and handles many operations, but a single monolithic tool feels thin for a domain that typically benefits from separate read, update, and delete capabilities.
The tool covers creation, updating, and rendering of trips, but there are no explicit delete, list, or get-by-id operations. The returned trip id supports updates, yet lifecycle coverage is incomplete for a full planner.
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. | |
| guests | No | Optional party size. | |
| focusDay | No | 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. | |
| 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 goes well beyond the annotations' readOnlyHint=false and destructiveHint=false. It discloses the full mutation and idempotency model: without `id` a new trip is created, with `id` the link stays the same and user map edits survive; there are no partial updates; stops and activities are reconciled rather than overwritten; geocoding behavior and coordinate-mismatch reporting are disclosed; editing behavior (dragging pins/routes) and cost estimates are described. This is rich behavioral context that annotations alone cannot convey.
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 information-dense; every sentence carries a distinct behavioral fact. The core purpose is front-loaded in the first sentence, and the most important operational rule (send `id` for existing trips) is repeated where it matters, in the `id` parameter. It loses one point because the opening paragraph is a dense run-on list of capabilities that could be better structured, and some repetition between the description and the `id` parameter description could be trimmed.
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?
The description accounts for all 7 parameters, the output (map link, structured trip, `id`), edge cases (no stops, id-only call, focusDay usage, days omission), and the annotations' openWorldHint. With an output schema present, the description does not need to enumerate return fields in detail, and what it does state about the result rounds out the picture. Nothing an agent needs to decide whether and how to call this tool 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 semantic value beyond the schema: it explains the create-vs-update semantics of `id`, the reconciliation rules for stops and activities, the geocoding/coordinate mismatch behavior, the day-view interaction for `focusDay`, and the 'no partial updates' rule for `days`. This is far beyond what the property descriptions alone provide, so a 5 is warranted.
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 precise verb+object pair ('Creates a road trip... or updates one... and returns an interactive map') and enumerates the exact mutations it supports: adding, removing, reordering, renaming stops, changing nights, dates, party size, and redrawing the route. It also explicitly contrasts itself with nothing to render ('a single destination or a route with no stops to draw has nothing to render'), which disambiguates its scope even without siblings.
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 concrete when-to-use guidance: use it to plan or update a trip, send `id` when the call is about a trip already plotted, and leave `days` out when only changing the route to preserve the saved itinerary. It also states the negative case ('a single destination or a route with no stops to draw has nothing to render'), which tells an agent when not to call it. The `id` parameter description carries an extensive when-to-send/when-not-to-send explanation.
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. Dates show when Glama detected each change.
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"
+}plot_trip2 fields changedInput schema / properties / days / descriptionPrevious value: -"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 deliberately rewriting the itinerary — it REPLACES the saved one wholesale, there are no partial day updates. 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."New value: +"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."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` — the call replaces the itinerary rather than merging into it, and there are no partial updates. The map link then stays the same, and edits the traveller made on the map survive: a re-sent stop keeps the position they dragged it to, and stops or waypoints they added on the map but absent from `stops` are kept, while a stop that was there before and is now omitted is removed. Without an `id` a separate new trip is created and none of those map edits carry over. Sending `id` with no `stops` is also accepted and changes nothing — it returns the trip exactly as saved."New 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."Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
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.
Route optimization for delivery fleets: plan, edit, and re-optimize multi-stop routes by prompt.
