Files
TREK/wiki/MCP-Setup.md
T
Maurice df3edac7b9 feat: six community requests — import dedup, accommodations in the feed, OAuth refresh race, visited-from-trip, journal jumps, phone packing rows (#1915)
* fix(places): match imports on the provider id so renamed places are not duplicated

Re-importing a Google Maps list duplicated every place the user had renamed.
buildDedupSet only ever collected names and, for unnamed places, coordinates,
and isPlaceDuplicate returns on the name before it reaches the coordinate
fallback, so a renamed place was findable by neither. The ids were stored all
along, and even backfilled onto matched places, they were simply never read.

Match on google_place_id / google_ftid / osm_id first, keeping name and
coordinates in their old roles below it. Widening the coordinate check instead
would have merged the restaurant and the bar in the same building.

The collection copy carried a hand-mirrored port of the same predicate; it now
uses the shared helpers and gets the fix with them.

Closes #1550

* feat(calendar): put accommodations into the subscribed feed as all-day stays

A hotel keeps its dates on the linked stay, not on the reservation: the booking
form writes reservation_time = NULL for type 'hotel', and day_accommodations
carries start day, end day and the check-in/out clock. The feed only ever read
the reservation, so a stay showed up once on the arrival day at best, and not at
all when it came from the booking form.

Join the stay in and emit the reservation as an all-day range over every night,
which also keeps it correct when days are reordered later — the dates now come
from the day rows rather than from the copy stamped at creation time. Check-in
and check-out become their own timed events when the stay records a clock,
because an all-day event cannot carry the time you actually need reminding of.
The check-in window, when set, becomes that event's DTEND.

Closes #1586

* fix(oauth): treat a concurrent refresh as a race, not as a stolen token

Refresh rotation is a race by construction. Several MCP clients share one
refresh token, both post it within the same second, and the loser was read as a
replay: chain revoked, MCP sessions torn down, browser window asking to log in
again. That is the daily re-authentication people were seeing, not a short
lifetime — access tokens last an hour and refresh tokens roll for thirty days.

A revoked refresh token now only counts as a replay once it is outside a
30-second grace window, and only when the rotation that revoked it left a
successor still alive. Inside the window the caller gets its own pair branched
off the same parent, so both clients walk away with a working token. Explicit
revocation leaves no live successor and a chain killed by a real replay has none
either, so neither can slip through the window.

Closes #1007

* feat(collections): mark a place visited from the trip it belongs to

A place saved in several lists had to be opened in each of them to say you had
been there, which is the wrong way round: you find out you have been somewhere
while looking at the trip, not while browsing the library.

The save picker now shows each list's own status and cycles it in place, with one
action for "visited, wherever this is saved". The planner's selection bar and the
mobile bulk toolbar carry the same thing for a whole selection — select all, one
tap, done. Matching happens on the server with the signals findMembership already
uses plus the source link a place saved from this trip carries, so a copy renamed
inside a list is still found. Lists you may only read are skipped rather than
refused; a shared list you cannot edit should not stop you marking your own.

Closes #1469

* feat(journey): jump to the top or back to the last entry in a long journal

Everything that adds to a journal sits at the top — the entry button, the
gallery upload — and where you left off sits at the bottom, so adding one photo
to a long journey meant scrolling the whole way twice.

Two buttons float over the middle of the feed, clear of the Add Entry column on
one side and the reorder arrows on the other, each appearing only when there is
more than a screenful to travel in that direction. They live in a zero-height
sticky box so they take no layout space and never push the timeline around.
While in the header, the status pill also picks up the height of the round
buttons beside it.

Closes #1088

* fix(packing): give the item name the row back on phones

An item name had roughly a third of the row to itself: a spelled-out sharing
sentence, an empty weight column and two round action buttons took the rest, so
anything longer than a word was cut off.

Sharing is now the icon it always was next to a label rather than a sentence in
the layout, an unset weight prints nothing instead of a dash, and edit/delete
sit behind one overflow button that opens the same inline menu the bag picker
already uses. The to-do list needed none of this — it wraps its chips onto a
second line already.

Closes #1525

* docs(wiki): cover the six community changes

- Calendar feeds: accommodations as an all-day range plus check-in/check-out
- Collections: setting the visited status from a trip, and how places are matched
- Journey: the jump buttons on a long journal
- Packing: what the phone row keeps and what moved behind the overflow button
- Places: re-importing a list no longer duplicates renamed places
- MCP setup: the rotation race no longer ends an OAuth session

* test(collections): assert the stored status instead of a private method

tests/ sits outside the build tsconfig, so reaching into getPlaceById only
showed up in the dedicated typecheck step. Reading the row is the better
assertion anyway — it pins what was persisted, not what a getter returns.
2026-08-12 17:43:22 +02:00

8.3 KiB

MCP Setup

This page explains how to connect an AI assistant to your TREK instance. TREK supports three authentication methods: OAuth 2.1 with browser consent (recommended for interactive clients), machine clients with no browser login (recommended for AI agents and scripts), and static API tokens (deprecated).

MCP Setup

Cloudflare users: If your TREK instance is proxied through Cloudflare, Bot Fight Mode and Super Bot Fight Mode will block MCP requests from ChatGPT. Claude.ai is not affected. See Troubleshooting → MCP requests blocked by Cloudflare WAF for the fix.

OAuth 2.1 is the preferred connection method. You grant specific scopes during the consent step and no token management is required afterward — TREK issues short-lived access tokens and automatically rotates refresh tokens.

Claude.ai

Claude.ai (web) supports native MCP connections — no JSON config file required:

  1. In TREK, go to Settings → Integrations → MCP → OAuth Clients and click Create.
  2. Select the Claude.ai preset. This fills in the redirect URI (https://claude.ai/api/mcp/auth_callback) and a default scope set.
  3. Give the client a name, adjust scopes if needed, and save. Copy the client ID and client secret (trekcs_ prefix) — the secret is shown only once.
  4. In Claude.ai, open the MCP settings and add a new server using your TREK URL (https://<your-trek-instance>/mcp). Claude.ai will open your browser to complete the OAuth consent flow.

Claude Desktop

Claude Desktop supports native MCP connections — no JSON config file required:

  1. In TREK, go to Settings → Integrations → MCP → OAuth Clients and click Create.
  2. Select the Claude Desktop preset. This fills in the redirect URI and a default scope set.
  3. Give the client a name, adjust scopes if needed, and save. Copy the client ID and client secret — the secret is shown only once.
  4. In Claude Desktop, open Settings → MCP and add a new server using your TREK URL (https://<your-trek-instance>/mcp). Claude Desktop will open your browser to complete the OAuth consent flow.

Cursor, VS Code, Windsurf, and Zed

Clients that support mcp-remote can connect in one of two ways.

Option 1 — dynamic registration (no pre-created client needed):

{
  "mcpServers": {
    "trek": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://<your-trek-instance>/mcp"
      ]
    }
  }
}

When the client starts, it fetches TREK's OAuth discovery document (/.well-known/oauth-authorization-server), registers itself automatically, and opens your browser to the TREK consent screen. You choose scopes there.

Option 2 — pre-created OAuth client:

Create a client in TREK using the appropriate preset (Cursor, VS Code, Windsurf, or Zed — all use http://localhost as redirect URI), then pass the credentials via --static-oauth-client-info:

{
  "mcpServers": {
    "trek": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://<your-trek-instance>/mcp",
        "--static-oauth-client-info",
        "{\"client_id\": \"<your_client_id>\", \"client_secret\": \"<your_client_secret>\"}"
      ]
    }
  }
}

On Windows, npx may need a full path, for example C:\PROGRA~1\nodejs\npx.cmd.

Requirement: APP_URL must be set on the server for OAuth discovery to work.

Pre-created OAuth clients

Settings → Integrations → MCP → OAuth Clients lets you create named OAuth clients before connecting. This gives you:

  • A fixed, named scope list defined up front
  • A client secret (trekcs_ prefix, shown once) for confidential client mode
  • Preset buttons for Claude.ai, Claude Desktop, Cursor, VS Code, Windsurf, and Zed that fill in the correct redirect URIs and a sensible default scope set

Each user can have up to 10 OAuth clients.

Option B: Machine client — no browser login (for AI agents and scripts)

Use this when your AI agent or automation script needs to authenticate silently without any browser interaction. Instead of going through an OAuth consent flow, the client exchanges a client_id and client_secret directly for an access token (RFC 6749 §4.4 — Client Credentials grant).

Why this exists: browser-based OAuth flows are an awkward fit for an agent running unattended. Two sessions sharing one refresh token used to be read as a replay, which revoked the whole chain and popped a login window; TREK now allows a short grace period on a just-rotated token, so a concurrent refresh no longer ends the session. Machine clients still sidestep the question entirely — there is no refresh token and no rotation at all.

How it works: the token acts as its owner (the user who created the client), scoped to the permissions chosen at creation. All TREK permission checks still apply — the AI agent can only access what you can access, narrowed further to the selected scopes.

Create a machine client

  1. Go to Settings → Integrations → MCP → OAuth Clients and click New Client.
  2. Tick Machine client (no browser login). The redirect URI field disappears — machine clients don't need one.
  3. Give it a name, select scopes, and click Register Client.
  4. Copy the client_id and client_secret shown — the secret is displayed only once.

How token management works

Your AI client uses the client_id and client_secret to request a token directly from TREK (POST /oauth/token with grant_type=client_credentials). Tokens are valid for 1 hour. When one expires, the client requests a new one silently — no browser window, no user action, no consent screen. This is handled entirely by the client.

Who should use this

Machine clients are designed for AI agent frameworks and custom MCP client implementations that can call the token endpoint themselves and handle renewal programmatically. TREK advertises client_credentials in its OAuth discovery document (/.well-known/oauth-authorization-server), so any compliant client can discover and use it automatically.

mcp-remote users: mcp-remote implements the browser-based authorization_code flow only — it does not support client_credentials. If you use mcp-remote, stick with Option A and use the preset for your client. The machine client option is not applicable.

Option C: Static API token (deprecated)

Deprecated: Static tokens will stop working in a future version of TREK. Migrate to OAuth 2.1 or machine clients.

Static tokens grant full access to all tools and resources with no scope restrictions. Sessions using a static token will receive deprecation warnings in the AI client on every tool call.

  1. Go to Settings → Integrations → MCP, open the API Tokens sub-tab, and click Create New Token.
  2. Give the token a name and copy it immediately — it is shown only once. The token starts with trek_.
  3. Pass the token as a header in your client config:
{
  "mcpServers": {
    "trek": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://<your-trek-instance>/mcp",
        "--header",
        "Authorization: Bearer trek_your_token_here"
      ]
    }
  }
}

Each user can create up to 10 static tokens.

Authentication reference

Method Grant Token prefix Access level Expiry
OAuth 2.1 — browser consent authorization_code trekoa_ Scoped (per-consent) 1 hour; auto-refreshed via 30-day rolling refresh token (trekrf_)
Machine client — no browser client_credentials trekoa_ Scoped (per-client), acts as owner 1 hour; re-request silently, no refresh token
OAuth client secret — trekcs_ Used to authenticate the client at the token endpoint No expiry (revoke via UI)
Static API token — trek_ Full access No expiry — deprecated