trips

Server Details

Hand someone a complete trip as a private, editable map link. No account, no API key, no card.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 46 days
Last Tested: 2026-10-02 01:24
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: peterbartsch/thistripbtw-mcp
GitHub Stars: 0
Server Listing: thistripbtw-mcp

TDQS

A4.4/5.0

Scored 2026-09-30 09:25 across 6 tools

Disambiguation4/5

Each tool has a distinct action (build/amend/read/add/find) and the descriptions explicitly cross-reference each other to steer selection. The one friction point is the draft (#d=) vs kept (#k=) split, which forces the agent to reason about link type before choosing read_trip_link vs read_kept_trip or amend_trip_link vs add_to_kept_trip, but the text cleanly disambiguates both pairs.

Naming Consistency4/5

All names lead with a verb and end in a resource noun (build_trip_link, amend_trip_link, read_trip_link, read_kept_trip, find_place), forming a predictable action_resource pattern. add_to_kept_trip is the mild outlier, inserting a preposition and placing the qualifier before the noun, but it remains readable and clearly scoped.

Tool Count5/5

Six tools is well-scoped for a trip-link builder: create, edit, two read variants, add-to-kept, and coordinate lookup. Each tool maps to a necessary step in the workflow and none feels redundant or padded.

Completeness3/5

The surface covers building, amending, reading, and adding stops, but the draft-to-kept transition itself has no tool even though both link states are modeled, and there is no delete/remove operation for a kept trip (amend's 'drop one' only applies to drafts). These are notable lifecycle gaps an agent cannot work around.

Available Tools

6 tools

add_to_kept_tripAInspect

Add a stop to a trip the person has KEPT (a link with #k=), on their behalf. Use when they say 'add X to the trip', 'we're stopping at Y on the way', 'put the hotel on it'. Needs their EDIT phrase — a view phrase can read but not write, and the tool says so. Writes exactly one stop and returns the trip's current stop count. Like read_kept_trip this touches the network: the #k= phrase is the password and it goes to thistripbtw.us over TLS, nothing is stored about you, and a wrong phrase counts as a guess. Treat the link as a credential.

ParametersJSON Schema

Name	Required	Description	Default
`link`	Yes	The kept trip's link with its #k= EDIT phrase.
`stop`	Yes	The stop to add.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	No	The new stop's id, when the server returned one.
`stops`	Yes	How many stops the trip has now.
`summary`	No

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the exact side effect ('Writes exactly one stop'), the return value, the network interaction with TLS, the no-storage guarantee, the guess-counting behavior for wrong phrases, and instructs treating the link as a credential. This is far richer than readOnlyHint=false and openWorldHint=true alone.

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

Conciseness5/5

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

Every sentence earns its place: purpose, trigger examples, prerequisite, side effect, network/security behavior, and credential warning. The most important information is front-loaded and there is no repetition of schema content or 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?

Given the nested stop object, six optional/property fields, external network dependency, credential handling, and output schema context, the description covers everything an agent needs to invoke it correctly: when to use it, what it writes, what it returns, and the security implications. No critical guidance appears missing.

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 description coverage is 100%, so the schema already explains every parameter. The description adds important semantic weight to `link` by calling the #k= phrase a password and a credential, and clarifies that exactly one stop is written; this justifies a small bonus above the baseline of 3.

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?

The first sentence states precisely what the tool does: add a stop to a kept trip on the person's behalf, and distinguishes it from read/build/amend siblings by targeting only kept links with #k=. This gives an agent a clear, non-tautological purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit user trigger phrases ('add X to the trip', 'we're stopping at Y on the way', 'put the hotel on it') and a clear precondition: the EDIT phrase, since a view phrase can read but not write. It does not explicitly name an alternative for view-only or non-kept trips, so it falls just short of full exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amend_trip_linkA

Read-onlyIdempotent

Inspect

Update a trip link you already built — add legs, change one leg's fields, replace them all, rename, or drop one — and get the new link back. Use this instead of building a fresh link every time the plan changes, so the person holds one link that grows. To change ONE leg (its lodging, date, note, who is on it) use update rather than resending every leg through legs. Takes a draft link (#d=) plus the changes; no network, no password, the trip is inside the link. For a KEPT trip (#k=) use add_to_kept_trip.

ParametersJSON Schema

Name	Required	Description
`add`	No	Legs to APPEND after the last one.
`legs`	No	REPLACES every leg. Omit to keep them.
`link`	Yes	The existing draft link, whole URL or just the #d= fragment.
`name`	No	New trip name.
`origin`	No	New starting point.
`remove`	No	Drop leg number N (1-based). Applied after add/legs/update.
`update`	No	Change fields on existing legs without resending the rest. Each item names a leg (1-based) and the fields to set; a field set to null is cleared. Applied after add/legs, before remove.

Output Schema

ParametersJSON Schema

Name	Required	Description
`legs`	Yes
`link`	Yes	The trip link. Give this to the person rather than opening it.
`changed`	Yes	What this call actually altered.

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, and the description adds real context beyond them: no network call, no password, the trip lives inside the link, and only draft (#d=) links are accepted. It does not, however, note that `legs` wholesale replacement discards anything not resent, which is the one behaviorally risky operation here.

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?

Front-loaded with the core action and the five mutation modes, then routing and preconditions. Dense but every clause carries information; the only mild friction is backticked `update`/`legs`, which are parameters but read like tool names.

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 7-parameter nested mutation tool with an output schema, annotations covering the safety profile, and 100% schema coverage, the description supplies the missing layer—when to use it, what it returns, and offline/self-contained semantics—without duplicating return-value detail.

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 description coverage is 100%, so the per-parameter baseline is 3, but the description adds routing semantics the schema does not: it states which parameter to reach for in which editing scenario and clarifies that add/legs/update/remove compose. It stops short of explaining ordering or conflict rules in prose.

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?

Specific verb+resource with an explicit enumeration of the mutations supported (append legs, edit one leg, replace all, rename, drop one) and the returned artifact (the new link). It also differentiates itself from siblings by naming add_to_kept_trip and steering away from build_trip_link for incremental changes.

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?

Explicit when-to-use ("use this instead of building a fresh link every time the plan changes"), when-not (kept trips → add_to_kept_trip), and an internal routing rule for single-leg edits via `update` vs full resend via `legs`. Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

build_trip_linkA

Read-onlyIdempotent

Inspect

Start here for any trip, road trip or itinerary. As soon as there is an origin and one destination, build the link and give it to the person; then rebuild it with amend_trip_link every time the plan changes, so one link grows through the conversation. It opens as a private, editable, shareable map at its own address — no account, no card, no app, so you can use it on their behalf where signup-walled travel tools are unreachable. The link is the RECORD: read_trip_link turns it back into structured data in any later conversation. Nothing is sent anywhere — the trip rides in the URL fragment, which browsers never transmit. Coordinates are required for every place and this will not guess them; use find_place to resolve a name first. Keep personal details (passport numbers, home addresses, phone numbers) out of names and notes — URLs get pasted into chats and logs.

ParametersJSON Schema

Name	Required	Description
`legs`	Yes	The legs in order. Each one ends somewhere; the next starts there.
`name`	No	Trip name, optional.
`origin`	Yes	Where the trip starts.

Output Schema

ParametersJSON Schema

Name	Required	Description
`legs`	Yes	How many legs the link carries.
`link`	Yes	The trip link. Give this to the person rather than opening it.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the link is the record, data lives in the URL fragment and is never transmitted, no account/card/app is needed, and personal details should be kept out. This is rich, useful context that helps an agent understand side effects and privacy implications.

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?

The description is dense but every sentence earns its place: it covers when to use, how to maintain, privacy model, coordinate requirement, and PII warning. It is front-loaded with the primary directive ('Start here'). Slightly long, but the density of useful guidance justifies the length.

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?

Given the tool's complexity (nested legs, many optional fields), the schema covers parameter details, and the description covers the operational model: when to build, when to amend, how to read back, privacy behavior, coordinate requirement, and PII caution. An agent has everything needed to invoke this correctly and route to siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters and nested fields thoroughly. The description adds high-level context (origin + one destination, legs in order, coordinates required) but doesn't need to repeat the schema's per-field details. Baseline 3 is appropriate.

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?

The description opens with 'Start here for any trip, road trip or itinerary' and states a specific verb+resource: build the link once origin and one destination exist. It clearly distinguishes itself from siblings by naming amend_trip_link and read_trip_link and explaining the link lifecycle.

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?

The description explicitly says when to use this tool ('Start here', 'as soon as there is an origin and one destination'), when to use amend_trip_link ('rebuild it ... every time the plan changes'), and when to use find_place ('use find_place to resolve a name first'). It also gives a clear exclusion: coordinates are required and the tool will not guess them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_placeA

Read-onlyIdempotent

Inspect

Turn a place name into coordinates for build_trip_link — towns, cities, airports (IATA or name), parks, trailheads. Returns up to six candidates with lat/lng and where each one is, so you can pick the right Reno. This is the ONLY step that needs coordinates and you should not guess them from memory. It asks thistripbtw.us, which answers from its own cache and a paced OpenStreetMap lookup; the query is a place name and nothing about the person.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The place as a person would say it: "Moab, UT", "SFO", "Arches National Park".

Output Schema

ParametersJSON Schema

Name	Required	Description
`results`	Yes	Up to six candidates, best first.
`summary`	No

TDQS

A4.8/5.0

Behavior5/5

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

The description discloses the backend (thistripbtw.us), cache and paced OpenStreetMap lookup behavior, and the privacy property that the query contains nothing about the person. These details go beyond the annotations (readOnlyHint, openWorldHint, idempotentHint) and add meaningful context about network behavior and data handling.

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?

Four sentences, each carrying distinct information: purpose, output behavior, usage rule, and backend/privacy. There is no fluff, though it is slightly longer than the absolute minimum. Every sentence earns its place and the purpose is front-loaded.

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 one-parameter tool with an output schema and annotations present, the description covers purpose, when to use, candidate output behavior, backend dependency, and privacy. There is no obvious gap an agent would need to call this tool correctly.

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?

With 100% schema description coverage, the baseline is 3. The description adds a specific list of accepted place types (IATA or name, parks, trailheads) and clarifies that the query should be just a place name, not personal information. This enriches the parameter's semantics beyond the schema examples.

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?

The description states a specific verb and resource: 'Turn a place name into coordinates for build_trip_link,' and enumerates supported place types (towns, cities, airports, parks, trailheads). This clearly distinguishes it from sibling trip-manipulation tools and leaves no ambiguity about what the tool does.

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?

It explicitly says 'This is the ONLY step that needs coordinates and you should not guess them from memory,' which both tells when to use the tool and warns against an alternative (guessing). It also guides selection among candidates with 'so you can pick the right Reno,' providing clear context for the intended workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_kept_tripA

Read-onlyIdempotent

Inspect

Use when someone gives you a KEPT this trip, btw link — one that looks like https://thistripbtw.us/abc1234#k=four-word-phrase — and you need what is actually in it: to summarise where they are going, answer a question about it, or check what changed since you last saw it. Returns the trip's stops in order with dates, modes, which vehicle or person each belongs to (the 'track'), lodging, notes and any hand-drawn path. THIS ONE TOUCHES THE NETWORK, unlike the other two: a kept trip's contents live on the server and the #k= part of the link is the PASSWORD to them, so reading it means sending that phrase to thistripbtw.us over TLS. Nothing is stored and no account is involved. Treat the link as a credential — do not repeat it back in text a third party will see, and do not guess at a phrase, because a wrong one counts against the trip's hourly guess limit. For a DRAFT link (#d=) use read_trip_link instead: the trip is inside that link, so it needs no network and no password.

ParametersJSON Schema

Name	Required	Description	Default
`link`	Yes	The kept trip's link, e.g. https://thistripbtw.us/abc1234#k=lagoon-passport-teal-teal. The whole URL is fine.

Output Schema

ParametersJSON Schema

Name	Required	Description
`trip`	Yes	A trip somebody bought, as this phrase is allowed to see it.
`stops`	Yes
`summary`	No

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 by disclosing that this call touches the network over TLS, that the #k= fragment is a password sent to thistripbtw.us, that nothing is stored and no account is required, and that wrong guesses count against an hourly guess limit. It also advises treating the link as a credential, none of which is captured by readOnlyHint/openWorldHint.

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?

Front-loaded with the use condition and the payload summary; every sentence carries information (network behavior, credential handling, sibling routing). It is a dense single block, slightly long, but with no filler or repetition.

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 one-parameter tool with an output schema, the description still summarizes the returned shape (ordered stops, dates, modes, track, lodging, notes, path), states the safety/credential model, and covers the only real failure mode (wrong password / guess limit). Nothing an agent needs to call it correctly is missing.

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 100%, so the baseline is 3, but the description adds real meaning: the #k= portion is the password/credential and a wrong phrase is penalized by a guess limit, plus it clarifies that the whole URL is acceptable. This exceeds what the schema's own example conveys.

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 and resource ('read a kept trip', returning its contents) and immediately names the sibling it is not: 'For a DRAFT link (#d=) use read_trip_link instead'. An agent can distinguish it from read_trip_link, build_trip_link and amend_trip_link without opening any 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 explicit triggering conditions (a 'KEPT this trip, btw' link of the #k= form, when you need to summarise, answer a question, or detect changes) and explicitly routes the alternative case (#d= draft links) to read_trip_link. Nothing about when-to-use is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_trip_linkA

Read-onlyIdempotent

Inspect

Use when someone gives you a this trip, btw link and you need to know what is actually in it — to summarise the plan, answer a question about it, add a stop, or convert it to something else. Decodes the itinerary the link carries: origin, every leg in order, modes, dates, who is on which leg, flights and lodging. Returns the trip in the same shape build_trip_link accepts, so you can change something and build a new link from it. Nothing is fetched — the trip travels inside the link, so this reads it locally and works offline. Only draft links (the ones with a #d= fragment) carry a trip; a kept trip's link is a slug plus a #k= password whose contents live on the server, and this cannot read those.

ParametersJSON Schema

Name	Required	Description	Default
`link`	Yes	The trip link, e.g. https://thistripbtw.us/new#d=… — the whole URL is fine, or just the fragment.

Output Schema

ParametersJSON Schema

Name	Required	Description
`legs`	Yes
`trip`	Yes	The trip, in exactly the shape build_trip_link takes — so it can be rebuilt or amended without translation.
`summary`	No

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value beyond these by explaining 'Nothing is fetched — the trip travels inside the link, so this reads it locally and works offline' and clarifying the draft-vs-kept limitation. This enriches the agent's understanding of behavior without contradicting any annotation.

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?

The description is a single paragraph but well-structured: usage first, then what it returns, then behavioral note, then limitation. Every sentence adds information, but it's slightly longer than strictly necessary—though each part serves a purpose, so it remains appropriate. Front-loading the use case ensures the agent finds the key decision point quickly.

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 single-parameter tool with an output schema and strong annotations, the description fully covers what the tool does, when to use it, its offline nature, and its limitation with kept trips. The agent can safely decide whether to invoke this or use a sibling, and knows exactly what input to provide and what to expect. Nothing essential is missing.

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 covers the link parameter with example URL and acceptance of whole URL or fragment. The description adds critical semantics: the link must be a draft link (#d= fragment) to carry a trip, and that it reads locally. With schema coverage at 100%, the baseline is 3; the additional draft-link constraint and offline behavior elevate it to 4.

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?

The description opens with a specific verb ('read') and resource ('trip link'), then elaborates on what it decodes: origin, legs, modes, dates, who is on which leg, flights, lodging. It immediately differentiates from siblings by stating that draft links carry a trip while kept trips do not, and by naming `build_trip_link` and `read_kept_trip` as related but distinct tools. This leaves no ambiguity about the tool's role.

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?

Explicitly instructs when to use: 'Use when someone gives you a this trip, btw link and you need to know what is actually in it' and lists common purposes. It also states the negative case: 'Only draft links... carry a trip... this cannot read those' which implicitly routes the agent to `read_kept_trip` for kept trips. This is clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 30, 2026

Changedamend_trip_link3 fields changed

changedInput schema / properties / remove / description

Previous value: -"Drop leg number N (1-based). Applied after add/legs."New value: +"Drop leg number N (1-based). Applied after add/legs/update."

addedInput schema / properties / update

Added value: +{
+  "description": "Change fields on existing legs without resending the rest. Each item names a leg (1-based) and the fields to set; a field set to null is cleared. Applied after add/legs, before remove.",
+  "items": {
+    "properties": {
+      "leg": {
+        "description": "Which leg, 1-based.",
+        "type": "integer"
+      },
+      "set": {
+        "description": "The fields to change — any leg field: to, mode, date, note, who, lodging, stayNote, flight, subtype, craft.",
+        "properties": {
+          "craft": {
+            "description": "A small craft that travels WITH them — a bike on the car, a canoe on the roof.",
+            "enum": [
+              "Bike",
+              "Canoe",
+              "Kayak"
+            ],
+            "type": "string"
+          },
+          "date": {
+            "description": "YYYY-MM-DD. Optional — an undated leg keeps its place in the order.",
+            "type": "string"
+          },
+          "flight": {
+            "description": "Flight number if you have it, e.g. UA328. Never invent one.",
+            "type": "string"
+          },
+          "lodging": {
+            "description": "Where they stay at this destination — hotel, cabin, a friend's couch.",
+            "type": "string"
+          },
+          "mode": {
+            "description": "How they travel this leg. Defaults to drive.",
+            "enum": [
+              "drive",
+              "fly",
+              "train",
+              "ferry",
+              "water",
+              "bike",
+              "walk"
+            ],
+            "type": "string"
+          },
+          "note": {
+            "description": "Anything worth remembering about this leg. Optional.",
+            "type": "string"
+          },
+          "stayNote": {
+            "description": "Anything about the stay. Only meaningful alongside lodging.",
+            "type": "string"
+          },
+          "subtype": {
+            "description": "More precise than mode when you know it: own/rental/rv/taxi for drive, commercial/private for fly, canoe/kayak/sail for water.",
+            "enum": [
+              "own",
+              "rental",
+              "rideshare",
+              "taxi",
+              "bus",
+              "rv",
+              "commercial",
+              "private",
+              "heli",
+              "intercity",
+              "commuter",
+              "subway",
+              "tram",
+              "passenger",
+              "carferry",
+              "sail",
+              "motor",
+              "canoe",
+              "kayak",
+              "walk",
+              "hike",
+              "run",
+              "ebike"
+            ],
+            "type": "string"
+          },
+          "to": {
+            "description": "Where this leg ends.",
+            "properties": {
+              "lat": {
+                "description": "Latitude, -90 to 90.",
+                "type": "number"
+              },
+              "lng": {
+                "description": "Longitude, -180 to 180.",
+                "type": "number"
+              },
+              "name": {
+                "description": "How a person would say it, e.g. \"Moab, UT\".",
+                "type": "string"
+              }
+            },
+            "required": [
+              "lat",
+              "lng"
+            ],
+            "type": "object"
+          },
+          "who": {
+            "description": "Who travels this leg, if you know — e.g. [\"Mel\",\"Sam\"]. Lets the trip show who was where.",
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          }
+        },
+        "required": [],
+        "type": "object"
+      }
+    },
+    "required": [
+      "leg",
+      "set"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / changed / properties / updated
```
Added value: +{
+  "type": "integer"
+}
```

1 tool updateSep 28, 2026

Changedread_kept_trip1 field changed

changedInput schema / properties / link / description

Previous value: -"The kept trip's link, e.g. https://thistripbtw.us/abc1234#k=treeline-downpour-rolling-switchback. The whole URL is fine."New value: +"The kept trip's link, e.g. https://thistripbtw.us/abc1234#k=lagoon-passport-teal-teal. The whole URL is fine."

6 tool updatesSep 25, 2026

Changedadd_to_kept_trip1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "id": {
+      "description": "The new stop's id, when the server returned one.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "stops": {
+      "description": "How many stops the trip has now.",
+      "type": "integer"
+    },
+    "summary": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "stops"
+  ],
+  "type": "object"
+}

Changedamend_trip_link1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "changed": {
+      "description": "What this call actually altered.",
+      "properties": {
+        "added": {
+          "type": "integer"
+        },
+        "name": {
+          "type": "boolean"
+        },
+        "origin": {
+          "type": "boolean"
+        },
+        "removed": {
+          "type": "boolean"
+        },
+        "replaced": {
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "legs": {
+      "type": "integer"
+    },
+    "link": {
+      "description": "The trip link. Give this to the person rather than opening it.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "link",
+    "legs",
+    "changed"
+  ],
+  "type": "object"
+}

Changedbuild_trip_link1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "legs": {
+      "description": "How many legs the link carries.",
+      "type": "integer"
+    },
+    "link": {
+      "description": "The trip link. Give this to the person rather than opening it.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "link",
+    "legs"
+  ],
+  "type": "object"
+}

Changedfind_place1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "results": {
+      "description": "Up to six candidates, best first.",
+      "items": {
+        "properties": {
+          "lat": {
+            "type": "number"
+          },
+          "lng": {
+            "type": "number"
+          },
+          "name": {
+            "type": "string"
+          },
+          "where": {
+            "description": "The fuller name, for telling two same-named places apart.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "lat",
+          "lng"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "summary": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "results"
+  ],
+  "type": "object"
+}

Changedread_kept_trip1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "stops": {
+      "type": "integer"
+    },
+    "summary": {
+      "type": "string"
+    },
+    "trip": {
+      "description": "A trip somebody bought, as this phrase is allowed to see it.",
+      "properties": {
+        "access": {
+          "description": "What the phrase in the link grants.",
+          "enum": [
+            "edit",
+            "view"
+          ],
+          "type": "string"
+        },
+        "address": {
+          "description": "The trip's own address, without the phrase.",
+          "type": "string"
+        },
+        "expires": {
+          "description": "YYYY-MM-DD, or null while no end date is set.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "name": {
+          "type": "string"
+        },
+        "notes": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "stops": {
+          "items": {
+            "description": "One stop: title, lat, lng, and whatever else was filled in.",
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "tier": {
+          "type": "string"
+        },
+        "tracks": {
+          "description": "Track labels, when the trip uses them.",
+          "type": [
+            "object",
+            "null"
+          ]
+        }
+      },
+      "required": [
+        "address",
+        "stops"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "trip",
+    "stops"
+  ],
+  "type": "object"
+}

Changedread_trip_link1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "legs": {
+      "type": "integer"
+    },
+    "summary": {
+      "type": "string"
+    },
+    "trip": {
+      "description": "The trip, in exactly the shape build_trip_link takes — so it can be rebuilt or amended without translation.",
+      "properties": {
+        "legs": {
+          "items": {
+            "properties": {
+              "craft": {
+                "description": "A small craft that travels WITH them — a bike on the car, a canoe on the roof.",
+                "enum": [
+                  "Bike",
+                  "Canoe",
+                  "Kayak"
+                ],
+                "type": "string"
+              },
+              "date": {
+                "description": "YYYY-MM-DD. Optional — an undated leg keeps its place in the order.",
+                "type": "string"
+              },
+              "flight": {
+                "description": "Flight number if you have it, e.g. UA328. Never invent one.",
+                "type": "string"
+              },
+              "lodging": {
+                "description": "Where they stay at this destination — hotel, cabin, a friend's couch.",
+                "type": "string"
+              },
+              "mode": {
+                "description": "How they travel this leg. Defaults to drive.",
+                "enum": [
+                  "drive",
+                  "fly",
+                  "train",
+                  "ferry",
+                  "water",
+                  "bike",
+                  "walk"
+                ],
+                "type": "string"
+              },
+              "note": {
+                "description": "Anything worth remembering about this leg. Optional.",
+                "type": "string"
+              },
+              "stayNote": {
+                "description": "Anything about the stay. Only meaningful alongside lodging.",
+                "type": "string"
+              },
+              "subtype": {
+                "description": "More precise than mode when you know it: own/rental/rv/taxi for drive, commercial/private for fly, canoe/kayak/sail for water.",
+                "enum": [
+                  "own",
+                  "rental",
+                  "rideshare",
+                  "taxi",
+                  "bus",
+                  "rv",
+                  "commercial",
+                  "private",
+                  "heli",
+                  "intercity",
+                  "commuter",
+                  "subway",
+                  "tram",
+                  "passenger",
+                  "carferry",
+                  "sail",
+                  "motor",
+                  "canoe",
+                  "kayak",
+                  "walk",
+                  "hike",
+                  "run",
+                  "ebike"
+                ],
+                "type": "string"
+              },
+              "to": {
+                "description": "Where this leg ends.",
+                "properties": {
+                  "lat": {
+                    "description": "Latitude, -90 to 90.",
+                    "type": "number"
+                  },
+                  "lng": {
+                    "description": "Longitude, -180 to 180.",
+                    "type": "number"
+                  },
+                  "name": {
+                    "description": "How a person would say it, e.g. \"Moab, UT\".",
+                    "type": "string"
+                  }
+                },
+                "required": [
+                  "lat",
+                  "lng"
+                ],
+                "type": "object"
+              },
+              "who": {
+                "description": "Who travels this leg, if you know — e.g. [\"Mel\",\"Sam\"]. Lets the trip show who was where.",
+                "items": {
+                  "type": "string"
+                },
+                "type": "array"
+              }
+            },
+            "required": [
+              "to"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "name": {
+          "type": "string"
+        },
+        "origin": {
+          "properties": {
+            "lat": {
+              "description": "Latitude, -90 to 90.",
+              "type": "number"
+            },
+            "lng": {
+              "description": "Longitude, -180 to 180.",
+              "type": "number"
+            },
+            "name": {
+              "description": "How a person would say it, e.g. \"Moab, UT\".",
+              "type": "string"
+            }
+          },
+          "required": [
+            "lat",
+            "lng"
+          ],
+          "type": "object"
+        }
+      },
+      "required": [
+        "origin",
+        "legs"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "trip",
+    "legs"
+  ],
+  "type": "object"
+}

3 tool updatesSep 10, 2026
- Addedadd_to_kept_trip
- Addedamend_trip_link
- Addedfind_place
1 tool updateAug 13, 2026
- Addedread_kept_trip
1 tool updateAug 5, 2026
- Addedread_trip_link
1 tool updateAug 4, 2026
- First observedbuild_trip_link

Related MCP Connectors

aitrips.io B
io.aitrips
Plan trips on a map: routed transport, day-by-day itineraries, and a plan you can share.
Travel & Transportation Search App Automation
452
road-trip-planner A
com.stopful
Plot an AI-planned road trip onto an editable Stopful map — drive times, hotels & EV chargers.
Travel & Transportation Location Services
12
flingflyers A
com.flingflyers
Share an HTML page or PDF as a short public link. No account or API key, expires on its own.
Cloud Storage
32
BautaOAuth
app.bauta
Give anything your AI makes a real, private-by-default link. Say "share this with Bauta."
Developer Tools CI/CD & DevOps Cloud Platforms
2

Related MCP Servers

@maproll/mcpofficial
Data Visualization Location Services
maproll-io
A
license
A
quality
B
maintenance
Enables agents to turn structured data into production-ready static maps, returning rendered PNG and SVG URLs along with an editable map link.
Updated 19 days ago (2026-09-12 19:14 UTC)
4
229 npm
MIT
Map Canvas MCP
Location Services Data Visualization
diegodox
F
license
Not graded
quality
B
maintenance
Enables interactive map display with up to 50 marked places and optional route lines, using a bundled Leaflet UI and OpenStreetMap tiles.
Updated a month ago (2026-08-21 04:23 UTC)
-
Travel Animator MCP
Travel & Transportation Multimedia Processing Location Services
Lascade-Co
A
license
Not graded
quality
B
maintenance
Enables AI assistants to create animated travel route videos by describing a trip, planning a route, styling the animation, and rendering MP4 files locally. It supports multiple map styles, 3D vehicles, and real-road routing.
Updated 24 days ago (2026-09-08 09:47 UTC)
MIT
osm-mcp
Location Services Travel & Transportation
ni-c
A
license
A
quality
B
maintenance
A read-only MCP server for OpenStreetMap offering geocoding, routing, route optimization, isochrones, and POI search—requiring no API key and built for AI travel planning.
Updated 3 days ago (2026-09-29 11:57 UTC)
11
181 npm
2
MIT