Plot an AI-planned road trip onto an editable Stopful map — drive times, hotels & EV chargers.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.8/5 across 1 of 1 tools scored.
With only one tool, there is no possibility of selecting the wrong tool for a task. The tool's single purpose is clearly described, even though it handles multiple operations internally.
The sole tool name 'plot_trip' follows a verb_noun pattern, which is consistent. There are no other tools to create inconsistency.
A single tool for a road trip planner is severely under-scoped. The tool bundles creation, updating, rendering, and editing into one endpoint, which should be split into separate concerns like create_trip, get_trip, update_trip, and delete_trip.
The tool covers creating and updating trips but lacks explicit retrieval (without modification) and deletion operations. There is no way to list trips, making the surface incomplete for a typical CRUD domain.
plot_tripAInspectCreates 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 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 | 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. | |
| 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. 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. | |
| 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. | |
| 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, when one was supplied. |
| 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. |
| 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?
Beyond the annotations (write, non-destructive), the description discloses substantial behavior: update replaces rather than merges, map edits survive re-sending a stop, geocoding occurs for coordinate-less stops, and far-off coordinates are reported. This is rich context beyond what readOnly/destructive hints 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 structured and information-dense, front-loading the core function and then detailing edge cases. No sentence is wasted, though it could be trimmed slightly without losing meaning.
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 (updates, itinerary replacement, map editing), the description covers all major behaviors, result contents, and limitations. Combined with a rich schema and output schema mention, it is fully contextual enough for an agent.
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?
The input schema already covers all six parameters with detailed descriptions, so the baseline is high. The description adds extra semantics around geocoding fallback and coordinate validation, and explains the effect of sending an existing stop's `id` and coordinates. This complements the schema without redundancy.
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 and resource: 'Creates a road trip on Stopful, or updates one plotted earlier...' and enumerates specific operations (adding, removing, reordering stops, changing nights, dates, party size). This makes the tool's purpose unmistakable.
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 explicitly states when to use the tool (multi-stop road trips) and when not ('a single destination or a route with no stops to draw has nothing to render'). It also clarifies create-vs-update behavior via the `id` parameter, giving clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
