Skip to Content
Privacy

Privacy

This page summarizes the privacy behavior a developer needs to know when building against Traveler.md. It is a summary and it is not the legal document.

The binding privacy policy is at traveler.md/privacy . That policy is published by TravelAI Solutions Inc., doing business as TravelAI. Version 1.1 took effect on 9 July 2026. Where this page and that policy differ, the policy governs. Read it before you ship an integration.

What the MCP server can see

The MCP (Model Context Protocol) server at https://mcp.traveler.md/mcp reads and writes two things: the traveler’s Traveler.md, and each Trip.md the traveler has created. That is the whole surface. Everything in those files was written by the traveler, or written by an agent the traveler authorized.

What the MCP server does not collect

  • Payment data.
  • Booking references from third-party systems, unless the traveler chose to record one in a file.
  • Conversation history from the connected client. The server sees the tool call, not the chat around it.

Access is scoped and revocable

A traveler authorizes each client once, through OAuth 2.1. The client receives a token scoped to that traveler. The consent screen names each scope before the traveler approves it. There is no all-scopes grant, so request the minimum your agent needs. A read-only assistant needs three scopes: profile.read, trip.read, and trip.list.

Travelers revoke a connection from Connections on traveler.md . Revocation takes effect on the next tool call, not when the access token expires. The server re-checks the current grant on every call. Authentication covers scopes, token lifetimes, and revocation in full.

The traveler decides what is shared and with which tool, and an audit trail shows them what happened. Build for that. An integration that reads more than it needs, or writes without telling the traveler what it wrote, is visible to them.

Nothing on the MCP surface deletes

No tool the server exposes can delete a Trip.md. archive_trip moves a trip out of the active list, and the traveler can reverse that from their account. Design your agent around this. A traveler who wants data removed uses their account, not your integration.

Traveler rights this affects

Two commitments shape how an integration should behave. Both are stated in Support.

  • Export. A traveler can download their Traveler.md and every Trip.md at any time. The files are portable by design, so do not treat your copy as the only copy.
  • Account deletion. Deleting an account removes the traveler’s files and revokes every connected client token immediately. Handle a sudden authorization failure as a normal state, not an error to retry.

Analytics on this documentation site

This site uses Google Analytics 4 and Microsoft Clarity. Both are gated on consent, in two different ways.

  • Google Analytics 4 loads in every state, under Google Consent Mode v2. Every storage signal defaults to denied, so it sets no cookies and stores no identifiers until the visitor opts in.
  • Microsoft Clarity records sessions the moment its script runs, so its script is not injected at all until the visitor opts in.

Advertising signals stay denied in both states. This site requests no advertising consent. The choice is stored in one cookie shared across traveler.md and its subdomains, so a visitor decides once for all three sites. Change or withdraw the choice with the Cookie preferences control at any time.

Contact

Send privacy requests and data questions to privacy@travelai.com. See Contact for the other addresses.