WanderLuxe MCP

The plan an assistant produces usually dies in the chat window. Getting it into a product means copying it by hand, which nobody does.

• Twenty tools across the whole trip model: list, read, create and update trips; add, update and delete accommodations, activities, dining, transportation and expenses; read the budget.
• Items are added by date and resolved to the matching trip day on the server, so the model never guesses an internal ID.
• Times are floating wall-clock values with optional per-item time zones. A flight landing in another country does not shift the rest of the day.
• A date change that would drop days with bookings returns the at-risk days first and requires explicit confirmation.
• When a required field is not established in the conversation, the tool asks instead of guessing. Especially dates and names.

1. 01

   Start from the schema

   The trip and each of its five item types got a matching set of tools. No new data model, no sync layer.

2. 02

   Design tools around intent

   A model thinks in dates and names, not primary keys. The tools accept what the model has and resolve the rest server-side.

3. 03

   Add guardrails where mistakes are expensive

   Lossy operations confirm first. Missing required fields prompt a question. Time zones are display metadata, never arithmetic.

4. 04

   Use it every day

   The server is wired into the founder's own Claude setup, which is where the rough edges show up first. An on-demand eval suite exercises the tools.

Protocol

• Model Context Protocol (MCP) with OAuth 2.1 via Supabase

Runtime

• TypeScript, inside WanderLuxe's Express server

Data

• WanderLuxe's Supabase schema; every call checks access to the trip

Clients

• claude.ai as a custom connector
• Claude desktop and mobile
• Claude Code
• Any remote MCP client