Tripsy Now Has a CLI (and an MCP)

The official CLI replaces the direct writes I described in Reading and Writing Tripsy’s SQLite Database on macOS. Inspecting a database copy can still help with debugging; editing a live store is no longer the route I recommend.

Tripsy released an official CLI and an MCP server. Install the CLI in one line:

curl -fsSL https://tripsy.app/install_cli | bash

The installer drops two binaries: tripsy for the CLI and tripsy-mcp for running the MCP server standalone. Log in once and credentials go into the OS keychain:

tripsy auth login --username you@example.com

What the old approach cost

The SQLite method required quitting Tripsy before every write, backing up the database directory, managing WAL checkpoints, generating unique identifiers that avoided CloudKit tombstones, re-querying Z_PRIMARYKEY every session because it jumps during sync, and then opening each inserted row through the Tripsy UI to push it to CloudKit. Updates to existing rows were silently reverted. One wrong identifier and the row vanished on the second app open with no error.

That’s a lot of ceremony to fix a check-in date.

The CLI is the right tool

Fixing a hosting date or adding transportation uses commands like these. IDs, addresses, and dates below are examples:

tripsy hostings update --trip <trip-id> <id> --set starts_at='2026-06-07T22:00:00Z'
tripsy transportations create --trip <trip-id> --name 'Drive SF → Fresno' --transportation-type roadtrip

Commands map directly to the API: tripsy trips, tripsy activities, tripsy transportations, tripsy hostings, tripsy expenses, tripsy documents. Output is human-readable by default, JSON when piped or passed --json. Every response includes a breadcrumbs field suggesting follow-up commands.

A few things worth knowing:

Ask the subcommand before guessing flags. Run tripsy activities --help before building an activity command. Use the matching subcommand’s help for hosting or transportation edits.

tripsy request for everything else. Named commands cover the common cases. Raw API calls go through tripsy request for anything not yet wrapped.

tripsy doctor. Checks auth and connectivity. Start here if something misbehaves.

I prefer the CLI over the MCP for most things. The MCP hands control to an AI that interprets your intent — useful for open-ended planning, but less predictable for precise edits. The CLI does exactly what you tell it.

Surprises

Two things I didn’t expect.

Every response includes a breadcrumbs field that suggests what to run next. After listing activities, the output tells you the exact command to show or create one. After creating a transportation, it gives you the show command with the new ID pre-filled. Most CLIs make you look this up. This one just tells you. It’s a small thing that makes the tool feel designed for exploration rather than assumed expertise.

In my May 2026 test, --set truncated values at the first space. Set an address with --set address='123 Example Street, Example City' and the stored value was 123. No error, no warning — just wrong data. The workaround is tripsy request PATCH with a --data JSON body, but that path had its own issues with endpoint discovery. For a tool that otherwise has good ergonomics, this is a jarring gap. Worth filing.

The MCP for planning conversations

The MCP is the better fit when you want to reason about a trip rather than edit specific fields. Add https://mcp.tripsy.app in Claude, sign in, authorize — done in under a minute. From there, Claude can read your trips, suggest activities, and adjust itineraries through natural language.

The Tripsy blog post announcing it frames it as iterative conversation rather than database management. That framing is right for planning. It’s less right when you need to fix a wrong departure time on a specific flight.

The SQLite post has mostly lost its value

The schema notes describe the store I inspected, not a stable Tripsy API. The CoreData epoch explanation is useful independently of that schema; table names and sync behavior need checking against your app version. If you’re debugging what Tripsy stores locally or building something directly on the raw data, it’s still a useful reference.

For anything else, the CLI is the better tool, and the SQLite approach no longer makes sense to reach for. The quit-Tripsy, backup-the-WAL, generate-a-fresh-identifier workflow existed because there was no alternative. Now there is.

The API has been available since May 2026. Use the CLI.