Authentication
The Traveler.md MCP server uses OAuth 2.1 with PKCE (S256). Each traveler authorizes a client once; the client receives an access token (short-lived) and a refresh token (long-lived) scoped to that traveler.
Most MCP clients don’t need any of the URLs below: point the client at the server URL (https://mcp.traveler.md/mcp) and it discovers the authorization server automatically via protected-resource metadata and authorization-server metadata . The endpoints are listed for clients that need to be configured by hand.
Endpoints
These endpoints run on connect.traveler.md.
| Purpose | URL |
|---|---|
| Authorization | https://connect.traveler.md/v1/oauth/authorize |
| Token | https://connect.traveler.md/v1/oauth/token |
| Token revocation | https://connect.traveler.md/v1/oauth/revoke |
| Dynamic client registration | https://connect.traveler.md/v1/oauth/register |
| JWKS | https://connect.traveler.md/v1/oauth/jwks.json |
| Authorization-server metadata | https://connect.traveler.md/.well-known/oauth-authorization-server |
| Protected-resource metadata | https://mcp.traveler.md/.well-known/oauth-protected-resource |
You do not need to register a client with us ahead of time. The authorization server supports dynamic client registration at the endpoint above, and most MCP clients register themselves through it automatically as part of the first connection. Registration needs no authentication, and the token endpoint accepts client_secret_post, client_secret_basic, or no client authentication at all for public clients using PKCE.
Scopes
A client must request the minimum scopes it needs. The consent screen shows the traveler exactly what they’re approving.
| Scope | What it allows |
|---|---|
profile.read | Read your Traveler.md |
profile.create | Create your Traveler.md |
profile.update | Update your Traveler.md |
trip.read | Read your trips |
trip.create | Create new trips |
trip.update | Update and archive your trips |
trip.list | List your trips |
There is no “all scopes” shortcut. Asking for more than you need is a fast way to lose a traveler’s trust. A read-only assistant, for example, only needs profile.read, trip.read, and trip.list.
trip.update covers both editing a trip and archiving it (archive_trip), because archiving is a reversible trip mutation rather than a separate capability. It does not grant deletion — nothing on the MCP surface can delete a trip.
Token lifecycle
- Access tokens are JWTs, valid for 15 minutes. Use them in the
Authorization: Bearer <token>header on MCP requests. - Refresh tokens are opaque, valid for 30 days of inactivity. Use the token endpoint to exchange them for new access tokens.
- A refresh token is rotated on every exchange; store the new one and discard the old.
Revoking access
Travelers manage and revoke connections from Connections on traveler.md , which lists every app they’ve authorized. Once a connection is revoked:
- The next MCP call fails as unauthorized, and the tool returns an authorization-revoked error rather than data.
- The client must walk the traveler through the OAuth flow again to reconnect.
Revocation and scope narrowing take effect on the next call, not when the access token expires. The server re-checks the traveler’s current grant on every tool call and compares it against the scope the call needs, so an access token minted before the change stops carrying the removed capability immediately — it does not stay valid for the rest of its 15-minute lifetime. Don’t build a client that assumes a grace window.
Clients can also call the revocation endpoint themselves when uninstalling.
What we do not collect
The MCP server only sees what the traveler has stored in their Traveler.md and Trip.md. It does not collect:
- Payment data
- Booking IDs from third-party systems unless the traveler chose to record them
- Conversation history from the connected client
For privacy specifics and data handling commitments, see Support.