Tripsy Now Has a CLI (and an MCP)

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 still has value

The schema documentation and CoreData timestamp explanation in the previous post aren't obsolete — if you're diagnosing what Tripsy stores locally, or building something on top of the raw data, the ZGENERALACTIVITY structure and Z_PK management are still accurate. The post was right about how Tripsy stores data. It was solving the wrong problem.

The API has existed since May 2026. Use that.