For AI assistants

The format

Base64url-encode a small JSON object and put it in the fragment:

https://thistripbtw.us/new#d=<base64url(JSON)>

A fragment is never sent to a server. Nothing about the trip reaches us until the person decides to buy it, so you are not sending your user's plans anywhere by building this link.

{
  "n": "Chicago to Denver",
  "o": { "name": "Chicago, IL", "lat": 41.8781, "lng": -87.6298 },
  "l": [
    { "to": { "name": "Omaha, NE",  "lat": 41.2565, "lng":  -95.9345 },
      "mode": "drive", "date": "2026-09-04" },
    { "to": { "name": "Denver, CO", "lat": 39.7392, "lng": -104.9903 },
      "mode": "fly",   "date": "2026-09-05" }
  ]
}

You must supply coordinates. We will not guess a location from a name, because guessing wrong puts someone's trip in the wrong country and it looks like our mistake. If you only have a place name, resolve it first.

Twelve worked examples live at /starts — one per shape of trip (two vehicles converging, a canoe leg, a rail loop, a crew joining partway). Each card is an ordinary #d= link: hand one over as a starting point, or read them to see the range this format carries.

Send everything you know. Anything unrecognised is dropped rather than rejected — a bogus subtype costs that one field, never the trip — so there is no downside to including who, stay or a flight number you are sure of.

One thing worth being exact about. This table describes the #d= payload — the JSON you base64url-encode yourself. The MCP tool takes the same trip in a slightly flatter shape: lodging and stayNote on the leg rather than a nested stay. Both are declared in the tool’s input schema, so a client that reads the schema gets it right; it is only a reader who follows this table into a tool call who would lose the lodging silently. Build the JSON by hand, or call the tool — just do not mix the two field sets.

We record; we don’t verify. Whatever you hand over is drawn as given — no flight, road, or date is checked against reality. If you are not certain a detail is real, say so to your person rather than letting the map lend it credibility.

What the person gets

• Their trip drawn on a real map, with driving legs following actual roads.
• Every part editable — you are handing over a first draft, not a finished thing.
• No account, no card, no email to look at it or change it.
• The draft lives in their browser only. Clearing data loses it; that is the honest trade for asking nothing of them.

If they want it to last, a one-time payment from $2.50 gives the trip a private address of its own and two share links, for a year to ten. That is the only paid step, and it is theirs to take — not something you can or should do for them.

Rules we would ask you to follow

• Don't put personal details in the link. Names of places, yes. Passport numbers, addresses, phone numbers — no. A URL gets pasted into chats and logs.
• Show the person the link before opening anything. It is their trip.
• Don't claim we said something we didn't. If you are describing what this is, what's free, what you pay for is accurate and short.

What we do with any of this

Nothing. There is no request to us when you build a link, so there is nothing to log. If the person later buys the trip, we store the trip's contents, and — only if they choose to make an account — their email and a list of which trips are theirs. No analytics, no trackers, no profiling, no selling. The complete list of what we keep and who we work with is on the privacy page, and it is exhaustive rather than reassuring.

Or install it as a tool

If your client speaks MCP, there is a server that does the encoding for you: six tools, zero dependencies, one readable file. Point your client at it and ask for a trip. Start with the link, not after the plan. As soon as there is an origin and one destination, build_trip_link turns them into a link; amend_trip_link rebuilds that link every time the plan changes, so the person holds one that grows; find_place resolves a place name to coordinates so you never guess them; and read_trip_link turns a link back into the legs, so you can summarise a trip someone hands you or pick up last week's plan without re-deriving it. None of those four touch the network except find_place, which asks our geocoder a place name.

read_kept_trip and add_to_kept_trip are the ones that reach a trip on our server, and it is worth knowing why. A trip somebody has bought lives on our server, and the #k= part of its link is the password to it rather than the trip itself — so reading one means sending that phrase to us. It returns the stops, the dates, which vehicle each belongs to and the notes; it does not hand back the raw server response, so the per-trip basemap token and the member roster stay where they are. Nothing is stored, and it needs no key. Treat a kept link as a credential, and do not guess at a phrase: a wrong one counts against that trip's hourly limit.

If your client takes a URL — most connectors do — point it at this and skip the download entirely:

https://thistripbtw.us/mcp

Nothing to install, nothing to keep updated. It is the same six tools, and it still does the encoding in the open: the trip rides in the link’s fragment, which browsers never send to a server, so it does not reach us even when someone opens it.

One thing worth knowing about gateways. Some directories and connector hubs — Smithery among them — list this server by proxying to the URL above rather than sending you straight to it. That works, and we publish there on purpose. But a proxy sees what passes through it, so a trip routed that way is read by whoever runs the gateway before it reaches us. We do not engage them and we cannot speak for what they keep. If that matters for what you are building, use the URL directly or run the file yourself — building a link locally makes no network call at all.

Prefer to run it yourself? The server is one file with no dependencies:

claude mcp add thistripbtw -- npx -y thistripbtw-mcp

Or fetch the file and run it yourself, if you would rather read it before you trust it:

curl -O https://thistripbtw.us/mcp/thistripbtw-mcp.mjs
claude mcp add thistripbtw -- node ./thistripbtw-mcp.mjs

One file, no dependencies, MIT, and short enough to read before you run it — the source is right there, under three hundred lines, and node ./thistripbtw-mcp.mjs --selftest checks it works without touching the network. There is a README as well. It is the same six tools as the URL above, so pick whichever you would rather trust.

Or take the Skill, and install nothing

If you would rather have instructions and a script than a running server, there is a Skill. It is a document plus one Python file with no dependencies, it makes no network call at all, and it produces exactly the same link — the two are checked byte-for-byte against each other on every build, so they cannot drift.

curl -O https://thistripbtw.us/agent-skill/build_link.py
python3 build_link.py --selftest

The skill document itself is at /agent-skill, and it is listed with its checksum at /.well-known/agent-skills/index.json so you can verify you got what we published.

Why a script rather than instructions. Hand-encoding base64url is exactly how you get a link that looks right and opens to nothing. The script is short enough to read and it self-tests offline, which is the same bargain as the server: check it before you trust it.

Two tutorials → Try it yourself →