Everything I wrote in Reading and Writing Tripsy's SQLite Database on macOS is now unnecessary.
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, adding a missing transportation, backfilling a confirmation number — these are two-line commands:
tripsy hostings update --trip 1094984 <id> --set starts_at='2026-06-07T22:00:00Z'
tripsy transportations create --trip 1094984 --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:
--help on every subcommand. tripsy activities --help shows syntax, examples, and common gotchas. Run it before guessing flag names.
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.
--set silently truncates values at the first space. Set an address with --set address='43011 N Fork Drive, Three Rivers, CA' and the stored value is 43011. 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 documentation and CoreData timestamp explanation are still accurate — the ZGENERALACTIVITY structure, Z_PK management, and CoreData epoch offset haven't changed. 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.
