Tripsy Has an MCP and a CLI Now

Everything I wrote in Reading and Writing Tripsy's SQLite Database on macOS is now the wrong way to do this.

Tripsy released an official MCP server and a CLI. The MCP gives Claude and other AI tools direct, typed access to your actual trip data — activities, transportation, stays, expenses, collaborators. The CLI wraps the same public API for terminal workflows and automation.

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 add a flight.

What the MCP gives you instead

Add the MCP server URL in Claude, sign in, authorize — done in under a minute. From there, Claude can read your trips, add activities, create transportations, and adjust itineraries through natural language. No WAL checkpointing. No CoreData timestamp arithmetic. No tombstone debugging.

The Tripsy blog post announcing it describes the intent: trip planning as iterative conversation rather than database management. That's the right framing. Travel plans change constantly, and the SQLite approach required treating every change as a surgical database operation.

The CLI for automation

The CLI covers the same surface through the terminal:

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. Credentials go through tripsy auth login once, stored in the OS keychain — no plaintext tokens sitting around.

A few things that work well in practice:

Output modes. Human-readable by default. Pipe it or pass --json and you get clean JSON envelopes. Every response includes a breadcrumbs array suggesting follow-up commands, which is useful when scripting.

--help on every subcommand. tripsy activities --help shows syntax, examples, and gotchas for that specific command. Worth running before guessing flag names.

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

tripsy doctor. Checks auth and connectivity. Run it first if anything misbehaves.

The CLI is where I spend most of my time with this. Fixing a hosting date, adding a missing transportation, backfilling a confirmation number — these are two-line commands rather than a conversation with an AI that may or may not interpret your intent correctly.

For scripted imports — pulling flight data from a KAYAK itinerary and creating transportation records in a loop — the CLI is the right tool. The SQLite method was my workaround for the same problem when no API existed.

The SQLite post still has value

The schema documentation and CoreData timestamp explanation in the previous post aren't obsolete. If you're building something on top of the Tripsy data locally, or diagnosing what the app is storing, understanding the ZGENERALACTIVITY structure and the Z_PK management is still useful. The post was accurate about how Tripsy stores data. It was just solving the wrong problem.

The correct way to programmatically add trips to Tripsy is through the API. May 2026 is when that became an option.